3 ms·

How to rate your code from A to F

3 points by johns 17y ago

mahmud 17y ago
I always write the most elegant demos and proof-of-concept code, and it goes down hill as it gets fleshed out. Later, I go back to rework it into a library and driver; all software can be made into a bunch of libraries and a "driver". Each library has a useable API, the driver code looks tight, but individual libs look really horrible behind the scenes. It's all engineering tradeoffs. The elegant things are sometimes slow or bloated, and the fast things are hackish and dirty. One thing that repeatedly screws me over is data representation. SQL tends to creep into the object system, because it's far cheaper to store and ID than a whole object. However, it's easier to store a whole object in memory than to make repeated trips to database. Language conveniences creep in; it's far easier for me as Lisper to parse a SQL row into a list, even easier to make that into a class instance. Regular expressions; keep those fuckers out of your code if you can help it, for anything but the first stage of a parsing script, regexes should be done without. One thing I found out is that "cushion" code, stuff that is meant to make your programming easier, remains in the program and never leaves. Instead of forgetting a horrible backdoor in the code, it's far easier to refactor it early and put the necessary debugging features in place. It's tempting to leave out error checking when you're not even sure you need the function to begin with, but we should be careful. I found out today that my FIND-USER function returned a valid USER object with a valid USER-ID but not login name or password. You chould actually go to www.mysite.com/home/USER-ID/ and be served a fresh account outside my billing system. Fuck me DEAD! P.S. Flow is a double-edged sword. If your code is brittle and academic, there might come a point one night when you type a few more forms and the whole things springs to life. It's beautiful to watch your creation come alive, you never want it to die, so your brain selects the kinds test data and you babysit your toy to full function avoiding all the embarassing crashes in between and possible throwing in the occassional IF-test to save face before yourself. You go and go, putting in more stuff and watch a few more milestones far from the distant future drop dead at your feet as you pass over them between coffee and cigarette breaks in that glorious night. Congratulations, you just caught the flow, here is hopping you will enjoy the next month of frustrated rewriting and fine-tooth combing through your inspired mess ;-)

3 points by johns 17y ago

I always write the most elegant demos and proof-of-concept code, and it goes down hill as it gets fleshed out. Later, I go back to rework it into a library and driver; all software can be made into a bunch of libraries and a "driver". Each library has a useable API, the driver code looks tight, but individual libs look really horrible behind the scenes. It's all engineering tradeoffs. The elegant things are sometimes slow or bloated, and the fast things are hackish and dirty. One thing that repeatedly screws me over is data representation. SQL tends to creep into the object system, because it's far cheaper to store and ID than a whole object. However, it's easier to store a whole object in memory than to make repeated trips to database. Language conveniences creep in; it's far easier for me as Lisper to parse a SQL row into a list, even easier to make that into a class instance. Regular expressions; keep those fuckers out of your code if you can help it, for anything but the first stage of a parsing script, regexes should be done without. One thing I found out is that "cushion" code, stuff that is meant to make your programming easier, remains in the program and never leaves. Instead of forgetting a horrible backdoor in the code, it's far easier to refactor it early and put the necessary debugging features in place. It's tempting to leave out error checking when you're not even sure you need the function to begin with, but we should be careful. I found out today that my FIND-USER function returned a valid USER object with a valid USER-ID but not login name or password. You chould actually go to www.mysite.com/home/USER-ID/ and be served a fresh account outside my billing system. Fuck me DEAD! P.S. Flow is a double-edged sword. If your code is brittle and academic, there might come a point one night when you type a few more forms and the whole things springs to life. It's beautiful to watch your creation come alive, you never want it to die, so your brain selects the kinds test data and you babysit your toy to full function avoiding all the embarassing crashes in between and possible throwing in the occassional IF-test to save face before yourself. You go and go, putting in more stuff and watch a few more milestones far from the distant future drop dead at your feet as you pass over them between coffee and cigarette breaks in that glorious night. Congratulations, you just caught the flow, here is hopping you will enjoy the next month of frustrated rewriting and fine-tooth combing through your inspired mess ;-)