Re: Code for readablity or fewer lines?

In code that may be maintained in the future, whether by myself or another, I will nearly always opt for readability. To ensure that I follow the best practices in production code, I follow my personal standards even in throw away code--primarily because I've found that I often take incorporate those bits into larger or later projects.

In my experience, line reduction is not a good benchmark for code quality. That's not to say that you shouldn't look for tighter ways to produce your code, but you should do judiciously. Obfuscation is fine for training or entertainment purposes, but it shouldn't be used in production.

I'm a member of the over documentation school, primarily because I have a memory like a steel sieve. If I'm not sure I'll remember why I chose a certain strategy in a week, a month, or a year, I write it down. If it's gonna confuse me, it will likely confuse the person that replaces me.

It's that simple. We're always decrying the lack or quality of documentation with the tools we use. Why, then, would we deliberately contribute to the problem in the tools we write?

For a better treatise on the subject, consider Code Complete. While it might be considered a bit dated by some and the examples are in C, the principles discussed are ones that every professional programmer/developer/anaylst should at least consider. (Also, if you pick up a copy by clicking that link, our tireless leader will get a small kickback.)

--f

Comment on Re: Code for readablity or fewer lines?

Replies are listed 'Best First'.
Re: Re: Code for readablity or fewer lines? by unixwzrd (Beadle) on Feb 27, 2001 at 22:09 UTC
I'll second that footpad, coding for clarity is best. People time is more expensive than machine time, and the divergence between the two gets wider every day. Optimization is good to the point where code starts to lose clarity. Unless the application has to be really optimized. It optimization is the case, then add copius comments so when you or someone else comes back a year later to enhance or fix it - again people time. I also agree, that I like to over-comment. A year from now I want to know what I was thinking when I go back and look at my code. Besides, comments don't add anything to the actual executable, they are discarded at compile time. Mike - mps@discomsys.com "The two most common elements in the universe are hydrogen... and stupidity." Harlan Ellison	[reply]
Re: Re: Re: Code for readablity or fewer lines? by howard40 (Beadle) on Feb 28, 2001 at 02:54 UTC
People time is more valuble than machine time. hehe ... that seems to be the driving motto of perl... :) if we were all hell-bent on maximum performance, most of us wouldnt be using perl at all but rather assembly or some language of that sort. i agree with you, readability almost always wins out over line count in my programs, however, dont mistake line count for efficiency line count doesnt always indicate a slower/worse script... sometimes adding a few lines into a script can substantially speed it up.	[reply]
Re: Re: Code for readablity or fewer lines? by Tuna (Friar) on Feb 28, 2001 at 01:10 UTC
"I'm a member of the over documentation school, primarily because I have a memory like a steel sieve. If I'm not sure I'll remember why I chose a certain strategy in a week, a month, or a year, I write it down. If it's gonna confuse me, it will likely confuse the person that replaces me" This rings especially true for me, as I have about a month's worth of programming experience. I am quite certain that I could've done things like use fewer variables and used `$key` for every single hash key, etc. I chose to use contextual variable names so, I, the inexperienced author, could go back, read, and understand what I have written! For example, `$private_file(@private_list)` and `$public_file(@public_list)`. Maybe I've gone a little overboard, but my assumption was that someone with little experience could very well end up with this code in their lap. Thanks everyone your perspectives.	[reply] [d/l] [select]