posted 22 years ago
As far as measuring lines of code goes, I'm afraid I can't add anything above what others have already said.
However, as far as the utility of counting lines of code as some sort of metric goes, I'm afraid that I'm very cynical. From my experience, the only utility of counting lines of code other than as a general indication of software complexity goes is is management is looking for something to flog the programmers with.
I can write some pretty tight code, though it may take longer to create. I can make it even tighter by omitting error-checking code (after all, that's non-productive code, right?). If I choose, I can even do the infamous obfuscated code trick, where the entire program is compacted into a single statement full of postfix operators, embedded multiple assignments and other dangerous tricks.
Conversely, I can unravel lots of code, do a lot of cut-and-paste work without doing any cleanup and otherwise be very sloppy but produce thousands of lines of code a day.
In either case, the "bean counters" may be happy, but the quality of the software - and thus, its usability and long-term cost - is likely to suffer.
Personally, I am one of those who think that "function points" are a better metric. The more decisions in a component, the more labor it will require and the more likelihood exists for bugs. However, any attempt to have technology mindlessly scan for "good" and "bad" is to me an abdication of managerial responsibility. Software isn't a uniform product like cheese. Sometimes the best solution is one that annoys the metrics.
By all means measure, but don't let the measurements become the goal at the expense of the product.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
