5 ms·

IMHO: 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,

by jmduke 14y ago

IMHO: 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.

famousactress 14y ago
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.]
reitzensteinm 14y ago
Make the code as short as possible, but no shorter?
- Flow 14y ago
  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?
solox3 14y ago
There is no correlation between line count and code quality.
- famousactress 14y ago
  Is it not likely a bell-curve? IE: Is it not likely that there's a correlation between high line count and average quality?
- reitzensteinm 14y ago
  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.
- sp332 14y ago
  Actually there is. https://news.ycombinator.com/item?id=3037293 https://news.ycombinator.com/item?id=3037293
- bunderbunder 14y ago
  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.
  - JoeAltmaier 14y ago
    - 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.

by jmduke 14y ago

famousactress 14y ago

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.]

reitzensteinm 14y ago

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

Flow 14y ago
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?

solox3 14y ago

There is no correlation between line count and code quality.

famousactress 14y ago
Is it not likely a bell-curve? IE: Is it not likely that there's a correlation between high line count and average quality?
reitzensteinm 14y ago
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.
sp332 14y ago
Actually there is. https://news.ycombinator.com/item?id=3037293 https://news.ycombinator.com/item?id=3037293
bunderbunder 14y ago
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.
- JoeAltmaier 14y ago
  - 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.