note
tedv
In my experience, Number of Lines is a completely meaningless
value. Here's a great example. Some people on my programming
team spent 4 months programming some software which took
30,000 lines (as counted by wc -l). They were applauded for
doing "good work". Later, I spent a mere 2 days culling
over the code and removing 3,000 lines. I was also applauded.
But if lines of code is a measure of work... doesn't removing
lines mean I'm destroying work?
<BR><BR>
Not at all, and everyone knows this. When I sorted through
the code, I was making it much more readable, understandable,
and just take advantage of many features which Perl allowed.
<BR><BR>
<B>Lines of code only measures the programmer's understanding
of the problem.</B>
<BR><BR>
It's very important to realize this. "Everything should be
made as simple as possible, but not simpler." If you have
too few lines of code, you might not fully understand the
problem. If you have too many lines of code, maybe you've missed an
elegant solution. But there's just no way to know if a
solution is "good" or "bad". You can only compare it to
other solutions..
<BR><BR>
A better metric of how well code is written is to go over
a section of code and explain it to someone else. Time how
long it takes for someone else to understand the body of code.
Your metric is <code>time / lines</code>. Note that line
counts include comments, because comments aide in the
(mis)understanding of the problem. This metric gives you a
far better understanding of true code ellegance.
Well written code will be easier to understand than poorly
written code.
<BR><BR>-Ted
75995
75995