On quality and code size

Posted by user on 26 Sep 2011

I recently came across a great blog post asserting - based on numerous studies - that size is the best predictor of code quality.

According to my own experience, this is spot on.

I can think of a couple of explanations:

  1. Concise code is generally the work of experienced and skilled developers.
  2. Removing dead code greatly increases code quality.
  3. Refactored code tends to be smaller (Adding features is not refactoring).

Point 2 and 3 result in a smaller code base and are a sign of a continuous code review process ("no code is set in stone" principle). In my experience, re-reading the code regularly is one of the greatest contributors to code quality, much more than unit testing and continuous integration (which are nevertheless required to make frequent refactoring possible).

I know that the best bug fixes I did were generally fixes that reduced the line count. Those bug fixes were generally a case of "Who the hell did something that complex for a problem that simple?! Oh wait, I did...".

In other words if you put efforts into code quality, this will generally result in reduced code size. This, to me, explains more the correlation between size and quality: concision is more an indicator of quality than a cause.

Topics: agile, process, programming, quality, Uncategorized, unit testing