The Myth of SLOC

Ah, that old favorite metric, Lines of Code, all the ubiquity of a spork and slightly less useful. Since we all (hopefully) know that SLOC is a useless metric, the obvious question is why would anyone use it? The simple answer is that it's so easy that a drunk chimp can calculate the metric!

As an example of why SLOC is useless, imagine two programmers at different companies implementing a paging functionality. Specifically, both programmers need to determine whether a next button and a previous button should be displayed. Programmer A produces the following code:

String n,p;
if(x&&y) {
n="enabled";
p="enabled";
} else if(x&&!y) {
n="enabled";
p="disabled";
} else if(!x && y) {
n="disabled";
p="enabled";
} else if(!x && !y) {
n="disabled";
p="disabled";
} else {
n="disabled";
p="disabled";
}


Wow, 16 lines of code! Programmer A's been pretty productive. Programmer B, on the other hand, came up with:

String next = hasNext ? "enabled" : "disabled";
String prev = hasPrev ? "enabled" : "disabled";


Wha? Only two lines of code? What a slacker! Oh, wait... both ultimately have the same effect! In fact, on closer examination, we find that Programmer A's code actually reduces the value of the code base! In case you're wondering how adding functionality could reduce value, consider the cost of maintenance. Those 16 lines, including a logically impossible else clause, will have to be read and understood by some poor soul if that file ever needs to be changed. Since none of the variables have meaningful names and the boolean clauses are more complicated than necessary, understanding Programmer A's code will take significantly longer.

So, if more lines of code aren't better, doesn't that mean that expressing the same thing in fewer lines of code is better? Turns out that the answer is a resounding... not necessarily. I'll expand on that a bit more in the next post, including touching on the myth that fewer lines of code implies fewer bugs.