A post on the Zennaware blog has ignited quite a discussion between developers on Twitter about the merit of the lines-of-code (LOC) metric for measuring code quality.

Zennaware develop Cornerstone, one of the best Subversion clients around. I used Cornerstone for several years, and if I were still using Subversion, probably still would be. It is a very capable and well designed app for Mac OS X.

The Zennaware post itself seems to be born out of a desire to defend their pricing of $59. Personally, I don’t think they need to do that. Quite aside from the fact that it is a pro tool, and $59 is not unreasonable, they have a right to charge anything they like and let the market decide.

But whether the post is necessary or not, it does bring up some interesting facts. The Cornerstone source code is apparently 180k lines, excluding whitespace, comments, and third party code. When I read that, it surprised me. As good as Cornerstone is, I found it difficult to imagine that an app of that kind would require 180k LOCs. My impression was that a codebase that big may not be adhering to the Don’t-Repeat-Yourself (DRY) principle, ie, may not be designed that well internally. (There is no question that the app’s user interface is very well designed.)

Several people, including Uli Kusterer, pointed out that LOCs are not a good measure of the size of a C code base. Whether you put your braces on a separate line, or spread out your method calls, could make a big difference to the number.

I found this an interesting question quite aside from the whole Cornerstone issue: How much do LOCs vary for algorithmically-equivalent code under different coding styles? So I did a test: I took a 1000 line piece of my code. I altered it to be as contracted as reasonable, putting method calls on one line, avoiding local variables, moving opening braces to the ends of lines, and things like that. I then made a second copy, spreading things out as much as I thought was reasonable: braces on separate lines; lots of local variables for intermediate results; method calls over multiple lines; that sort of thing.

And the results? Spread out code came to 798 LOCs (excluding empty lines and comments). Contracted code came to 604 LOCs. So contracted is around 25% less than spread out. That is more than I had expected. It still doesn’t make the 180k of Cornerstone seem compact — even assuming they have a spread-out code base, it would only drop to 140k or so with a contracted style — but it is a useful rule-of-thumb when considering the LOC metric in C-based code.

Want to comment? Go to our Tender.