When, if ever, is “number of lines of code” a useful metric?

Question

Some people claim that code\'s worst enemy is its size, and I tend to agree. Yet every day you keep hearing things like

• I write blah lines of code in a day.

Answer 1

I'd agree that taking the total number of lines of code in a project is one way to measure complexity.

It's certainly not the only measure of complexity. For example debugging a 100 line obfuscated Perl script is much different from debugging a 5,000 line Java project with comment templates.

But without looking at the source, you'd usually think more lines of code is more complex, just as you might think a 10MB source tarball is more complex than a 15kb source tarball.

Answer 2

It's a terrible metric, but as other people have noted, it gives you a (very) rough idea of the overall complexity of a system. If you're comparing two projects, A and B, and A is 10,000 lines of code, and B is 20,000, that doesn't tell you much - project B could be excessively verbose, or A could be super-compressed.

On the other hand, if one project is 10,000 lines of code, and the other is 1,000,000 lines, the second project is significantly more complex, in general.

The problems with this metric come in when it's used to evaluate productivity or level of contribution to some project. If programmer "X" writes 2x the number of lines as programmer 'Y", he might or might not be contributing more - maybe "Y" is working on a harder problem...

Answer 3

Reminds me of this:

The present letter is a very long one, simply because I had no leisure to make it shorter.
--Blaise Pascal.

Answer 4

There are a lot of different Software Metrics. Lines of code is the most used and is the easiest to understand.

I am surprised how often the lines of code metric correlates with the other metrics. In stead of buying a tool that can calculate cyclomatic complexity to discover code smells, I just look for the methods with many lines, and they tend to have high complexity as well.

A good example of use of lines of code is in the metric: Bugs per lines of code. It can give you a gut feel of how many bugs you should expect to find in your project. In my organization we are usually around 20 bugs per 1000 lines of code. This means that if we are ready to ship a product that has 100,000 lines of code, and our bug database shows that we have found 50 bugs, then we should probably do some more testing. If we have 20 bugs per 1000 lines of code, then we are probably approaching the quality that we usually are at.

A bad example of use is to measure developer productivity. If you measure developer productivity by lines of code, then people tend to use more lines to deliver less.

Answer 5

It's useful when loading up your line printer, so that you know how many pages the code listing you're about to print will consume. ;)

Answer 6

As most people have already stated, it can be an ambiguous metric, especially if you are comparing people coding in different languages.

5,000 lines of Lisp != 5,000 lines of C