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

It's a great metric for scaring/impressing people. That's about it, and definitely the context I'm seeing in all three of those examples.

Answer 2

When you are refactoring a code base and can show that you removed lines of code, and all the regression tests still passed.

Answer 3

The Software Engineering Institute's Process Maturity Profile of the Software Community: 1998 Year End Update (which I could not find a link to, unfortunately) discusses a survey of around 800 software development teams (or perhaps it was shops). The average defect density was 12 defects per 1000 LOC.

If you had an application with 0 defects (it doesn't exist in reality, but let's suppose) and wrote 1000 LOC, on average, you can assume that you just introduced 12 defects into the system. If QA finds 1 or 2 defects and that's it, then they need to do more testing as there are probably 10+ more defects.

Answer 4

Lines of code are useful to know when you're wondering if a code file is getting too large. Hmmm...This file is now 5000 lines of code. Maybe I should refactor this.

Answer 5

There is one particular case when I find it invaluable. When you are in an interview and they tell you that part of your job will be to maintain an existing C++/Perl/Java/etc. legacy project. Asking the interviewer how many KLOC (approx.) are involved in the legacy project will give you a better idea as to whether you want their job or not.

Answer 6

In competitions.