Yesterday I sat down to start work on a small project. Now, when I say small, it generally means less than 2,000 source lines of code (SLOC). For some people, that is huge — for other people, that is barely on the radar.
I find it interesting that, since I shifted from being primarily a Perl developer to being primarily a VB.Net developer, my perception of a small project has dramatically changed. When I was working in Perl, 200 SLOC was a small project. My experience has been that it takes between 500 and 1,000 SLOC of VB.Net to approximate 200 SLOC of Perl in terms of overall functionality. The standard response to this (and the usual takeaway) is, "Perl is more efficient than VB.Net in terms of SLOC." I generally agree with that statement, and there is research out there that proves it.
Here's the real question: Is SLOC the best measure of a piece of code?
Analyzing language syntax
Let us look at an example to see which of these two code snippets is really better.Code 1
Dim Obj as MemoryHog = New MemoryHogCode 2
Dim Val as String
Val = Obj.Property
Console.Writeline("Val is: " & Val)
Console.Writeline("Val + 1 is: " & Val + 1)Console.Writeline("Val * 1000 is: " & Val * 1000)
Dim Obj as MemoryHog = New MemoryHogBy the SLOC measure, Code 2 is significantly "better" than Code 1. But when you take a closer look under the hood, Code 1 has a number of advantages over Code 2. While it does take a bit more memory than Code 1 because of the extra variable Val, it is more efficient on the CPU, as it does not have to keep dereferencing Obj.Property. This is a common refactoring. Also consider that, while the latter portion of Code 1 is probably slightly less efficient on the CPU than the final, equivalent line in Code 2 because it has fewer function calls, it is simultaneously less efficient due to all of the concatenation in it. In fact, it has enough concatenations to make using the StringBuilder class a viable option. Additionally, it is a much more difficult (although still not "difficult") line of code to understand than the equivalent three lines from Code 1. As you can see, SLOC "efficiency" is hardly applicable, even within the same language.
Obj.FillWithTonsOfDataConsole.Writeline("Val is: " & Obj.Property & VbNewLine & "Val + 1 is: " & Obj.Property + 1 & VbNewLine & "Val * 1000 is: " & Obj.Property * 1000)
There is also the issue of the "cleverness" of code. I will be honest — I adore elegant code. An example is some of the tricks with UNIX pipes. I've also always liked the C convention where "true" means "not zero," which can save a ton of typing (compare the C-esque if (String.Length) to the VB.Net'y If Not String = String.Empty or If Not String = "" or If String.Length > 0).
The efficient language folks have an argument that goes like this:
- Each line of code is a potential point of failure.
- Each line of code takes time to plan, type, review, and debug.
- Fewer lines of code reduce failures and increase coding speed.
Well, yes and no. I agree with the two premises. But they also miss a few other premises that are demonstrated in my above examples, including:
- Clever code takes longer to plan, review, and debug than verbose code.
- Programmers who can work well with clever code and who can write clever code well are much rarer and expensive to hire (and probably harder to retain) than more verbose programmers.
- Clever code can have more points of failure per line of code.
- The real points of failure are variables, operators, and statements that make up a SLOC — reducing those is what truly reduces points of failure. One SLOC with the same number of operations and variables as 10 lines of code has just as many potential points of failure.
So, in many ways, it's a wash. I prefer the clever code much of the time, but I also recognize that I am in a small (but vocal) minority that is mainly populated at this point by old-time UNIX programmers. I think that the folks who enjoy and are good at reducing SLOC also happen to be an extremely experienced and talented group of people. This is going to throw off your comparisons. Give someone who is good at lowering SLOC the same project as a more verbose programmer and tell the SLOC person to be verbose, and they will probably still be better. I have not met anyone in this industry who lacks experience but screams "SLOC." It truly seems to be relegated to the Old Guard.
Becoming a more efficient programmer
At the end of the day, whether code is clever and reduces SLOC is fairly irrelevant in my book. Refactor the code to increase readability, reduce variable, statement, and operator count wherever possible and reasonable, and you are well on your way to becoming a higher quality, more efficient programmer.