People often measure size or complexity of a software project by counting Source Lines Of Code. While this can often show whether some source code is large or not (and therefore provide relative and crude estimates about productivity), relying on it can be fatal.
Textual source code can be considered to be only one arbitrary representation of software[1]. Depending on the language chosen the complexity of the code can vary greatly. I also hope it's obvious to any regular reader of this blog that systems have more than two dimensions, which instantly proves that the SLOC count can't tell anything about the complexity of the software.
Worse, while textual representation is two-dimensional, SLOC measures only one of it. Thus, trying to control complexity by creating constraints on the amount of SLOC is obviously critical.
If the code wants to grow, be it because of a rudimentary programming framework, better understanding of the problem by the programmer or something else, it can reach its upper limit without the problem becoming any more complex inherently. In fact, additional code might make the system even less complex.
When the vertical bound is (close to be) reached, growth will continue in horizontal direction. And hundreds of characters long lines with several statements are far more problematic than just adding them above.
Code growth should not be prohibited per se. It should be closely monitored whether it is benign. And as long as it is, it is the job of the programmer to transform the code so that it always has the best design possible.
- See also CodingStandardsAreMisleading