Having a high sloc number isn't necessarily good. Nor is having a low one.
Coding for readability and performance often results in fewer lines of code, but that's not a two-way street; coding specifically in order to reduce sloc doesn't magically make your code quicker or more readable.
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.]
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.
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.
Having a high sloc number isn't necessarily good. Nor is having a low one.
Coding for readability and performance often results in fewer lines of code, but that's not a two-way street; coding specifically in order to reduce sloc doesn't magically make your code quicker or more readable.