I think I might softly disagree. The difference (for me) is mentality. I kind of try to approach code and product design with sort of a calculus of approaching the limit of 0. My first goal is always to remove. Question the existence of the individual LOC, the feature, even the product... Of course, that's just the way I like to look at it, I may be doing it wrong.

I also think the readability argument is overused. I definitely value readability, but I rarely see aggressive code re-use lead to significant-enough readability challenges to warrant not doing it. More often the before/after are both pretty readable, and the after has half as many possible test-cases.

[Edit (almost immediately): Nevermind. I don't think anything I said is in conflict with anything you said. I probably ought to take the approach I have to code and apply it to commenting.]

Make the code as short as possible, but no shorter?

It's not that easy, you have to think of things like:

- If I debug this code, will there be meaningful intermediate values? (One clever line of code might lack those)

- Can a less experiences developer understand what this does?

There is no correlation between line count and code quality.

I suspect that if someone could come up with a reasonable way to single out confounding variables, there would prove to be an inverse correlation between SLOC per function point and code quality.

My rationales:

- More SLOC means more places for a bug to hide.

- More SLOC means more logic to have to reason about.

- More repetition leads to more SLOC.

- More repetition increases the chance that a bug can be fixed in one spot but not in others.

- More repetition increases the chance for regression bugs resulting from updates not being fully propagated

Anecdotally, on my team it seems that we tend to have the least quality issues in the stuff that's written by folks who produce the most factored code.

- Fewer SLOC means less code to compile and execute.

- Fewer SLOC means more code fits on one page.

- Fewer SLOC means it may be easier to explain/document/remember what it does.

Actually there is. https://news.ycombinator.com/item?id=3037293

Sure there is, if you control for functionality. You can't solve complex problems concisely without the right abstractions, and the right abstractions are 90% of the battle for code quality.

Is it not likely a bell-curve? IE: Is it not likely that there's a correlation between high line count and average quality?