3 ms·

No, "Lines of code" is not a meaningless metric. I recently had to take over an existing code base for a module in our system and upgrade it to support the nex

No, "Lines of code" is not a meaningless metric. I recently had to take over an existing code base for a module in our system and upgrade it to support the next version of our system's ICD. After spending some time trying to wrap my head around the existing 8800 lines of code, I concluded that it would be better to do a complete rewrite. The rewrite took a week or two and ended with 1950 lines of code that did essentially the same thing! Now, if we make the reasonable assumption that my rewrite was not a candidate for the IOCCC or Perl Golf, I think it's pretty clear that lines of code is not meaningless. A >75% code reduction while maintaining the same functionality under reasonable development conditions is almost always going to make it easier to test, debug, and maintain the system/module. (This assumption isn't unsubstantiated either. In a code review, I was even complimented on the quality of my documentation.) You hear about these kinds of vast disparities among software developers all the time, but I still find myself shaking my head that I actually saw it in real life. Now I'll freely admit that "lines of code" is mostly meaningless the way it is usually used. But don't throw the baby out with the bath water.

szx0 17y ago
What if your 1950 was less expressive and more cryptic to understand, and the 8800 was very verbose and easy for a newbie to pick up? So you can't measure less LOC means it's better, it really depends on the quality of the code from a maintainability standpoint not just the size of code.
- mightybyte 17y ago
  First of all, it wasn't. Like I said, as long as we assume reasonable effort towards readability (i.e. we're not code golfing), this kind of size difference is usually going to be much easier to maintain. Code size correlates very well with maintainability. The guy who did the code review found the 1950 very readable, and much simpler.
- mightybyte 17y ago
  On the other hand, the instant a manager starts making salary/bonuses proportional to the inverse of code size, you'll find that my assertion becomes completely false. But if you start from an empty slate of two developers making a genuine effort to code a good solution, the less LOC rule will probably be pretty accurate. Especially when one program is 4x the size of the other. (See http://paulgraham.com/head.html http://paulgraham.com/head.html for a related take on the same idea.) There are no absolutes. But that doesn't make these metrics useless.
  - wglb 17y ago
    There is actually one point missing from his list. I would put it after #5 and that is "write provable programs". I suspect Paul does this anyway, but it is a good thing to mention. This is scary to some, but PAIP has some very nice examples of this. And rereading this essay again shows at least part of the motivation for making arc a smaller language than lisp.

szx0 17y ago

What if your 1950 was less expressive and more cryptic to understand, and the 8800 was very verbose and easy for a newbie to pick up? So you can't measure less LOC means it's better, it really depends on the quality of the code from a maintainability standpoint not just the size of code.

mightybyte 17y ago
First of all, it wasn't. Like I said, as long as we assume reasonable effort towards readability (i.e. we're not code golfing), this kind of size difference is usually going to be much easier to maintain. Code size correlates very well with maintainability. The guy who did the code review found the 1950 very readable, and much simpler.
mightybyte 17y ago
On the other hand, the instant a manager starts making salary/bonuses proportional to the inverse of code size, you'll find that my assertion becomes completely false. But if you start from an empty slate of two developers making a genuine effort to code a good solution, the less LOC rule will probably be pretty accurate. Especially when one program is 4x the size of the other. (See http://paulgraham.com/head.html http://paulgraham.com/head.html for a related take on the same idea.) There are no absolutes. But that doesn't make these metrics useless.
- wglb 17y ago
  There is actually one point missing from his list. I would put it after #5 and that is "write provable programs". I suspect Paul does this anyway, but it is a good thing to mention. This is scary to some, but PAIP has some very nice examples of this. And rereading this essay again shows at least part of the motivation for making arc a smaller language than lisp.