How bad is SLOC (source lines of code) as a metric? [closed]

Answer 1

I disagree on SLOC being a bad metric. It may be moot to go into a years-old question with eleven answers, but I'll still add another.

Most arguments call it a bad metric because it is not suited to directly measure productivity. That is a strange argument; it assumes the metric to be used in an insane way. With this reasoning, one could call the Kelvin a bad unit because it is unsuited to measure distance.

Code length is a viable measure of ballast.

The amount of non-comment code lines correlates with:

• undetected errors
• maintenance costs
• training time for new contributors
• migration costs
• new feature costs

and many more similar kinds of costs, like the cost of optimization.

Of course SLOC count isn't a precise measure of any of these. Code can be anywhere between very nice and very ugly to manage. But it can be assumed that code length is rarely free, and thus, longer code is often harder to manage.

If I were managing a team of programmers, I would very much want to keep track of the ballast it creates or removes.

Answer 2

I believe SLOC is a great metric. It tells you how large your system is. That is good for judging complexity and resources. And it helps you prepare the next developer for working on a codebase.

But SLOC count should be analyzed only AFTER other appropriate code quality metrics have been applied. So...

• Do NOT write 2 lines of code when 1 will do, unless the 2-line version makes the code 2 times easier to maintain.
• Do NOT fluff code with unnecessary comments just to fluff SLOC count.
• Do NOT pay people by SLOC count.

I have been managing software projects for 30 years. I use SLOC count all the time, to help understand mature systems. I have never found it useful to even glance at SLOC count until a project is near version 1.0 release.

Basically, during the development process, I worry about quality, performance, usability, and conformance to specifications. Get those right, and the project will probably be a success. When the dust settles, look at SLOC count. You might be surprised that you got SO much out of 5,000 lines of code. And you might be surprised that you got SO little! (But SLOC count does not affect quality, performance, usability, and conformance to specification.)

And always code like the person who will be working on your code next is a violent psychopath who knows where you live.

Cheers, Uncle Chip

Answer 3

Answer 4

Show them the difference between:

for(int i = 0; i < 10; i++) {
    print i;
}

and

print 0;
print 1;
print 2;
...
print 9

And ask them whether 10 SLOC or 3 SLOC is better.

---

In response to the comments:

1. It doesn't take long to explain how a for loop works.

2. After you show them this, say "we now need to print numbers up to 100 - here's how you make that change." and show how much longer it takes to change the non-DRY code.

Answer 5

Explain that SLOC is an excellent measurement of the lines of code in the application, nothing else.

The number of lines in a book, or the length of a film doesn't determine how good it is. You can improve a film and shorten it, you can improve an application and reduce the lines of code.

Answer 6

Pretty bad (-:

A much better idea would to cover the test cases, rather than code.

The idea is this: a developer should commit a test case that fails, then commit the fix in next build, and the test case should pass ... just measure how many test cases the developer added.

As a bonus collect coverage stats (branch coverage is better than line coverage here).