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.]
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.
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.
My proudest commits are the ones that are never made, because I figured out how to avoid writing the code in the first place.
This is a skill, and I've been consciously working to improve it. I think the key questions are "Do I really need to write this now?" and "Is there a simpler problem I should be solving instead?"
And the beautiful thing is that we can see actual results of Bill Atkinson's philosophy. You can download the source of both MacPaint and QuickDraw from http://www.computerhistory.org/highlights/macpaint/.
It's in Pascal and 68k assembly, and I find it quite beautiful. Especially the Pascal code, as it is broken up into clear, concise functions so it is easy to understand what is going on.
An attempt at an earnest reply--
I've been reading HN for about a year (this is my first comment). Speaking as someone trying to tackle the impossibly massive field of "doing things on computers" by myself, I deeply appreciate that this isn't simply a "news website," and that the community raises issues that didn't just pop up in the last couple weeks. I've learned so much from articles that have been posted before that I never would have discovered otherwise, and I'm always a little bit disappointed when I see replies like this one. I understand concern about rapid reposts, but this was posted two years ago and then one year ago. The vitriol is completely unwarranted. Not all of us are seasoned veterans with knowledge going back decades or years or even months, no matter how much we probably wish that wasn't the case!
Unfortunately back then Apple was the epitome of the hacker-friendly, open culture company (waving a pirate flag on the building!) and nowadays they're the epitome of close-minded, control-freak behemoth, alas.
In software I have noticed that the best coders spend a lot of time removing code and the worst coders keep piling crud on top of crud on top of crud.
CSS seems to be really bad for this, but that might be because the frontend coders I have met are crappy. Rather than decrease the padding they'll ADD more css to move all of the elements, then they end up with !important rules everywhere.
I've been doing frontend web coding for more than 5 years now, and I have only had to use !important probably 3 or 4 times, and only them it was to overwrite things in stylesheets that we had no control over.
In software I have noticed that the best coders spend a lot of time removing code and the worst coders keep piling crud on top of crud on top of crud.
This is natural, if you think about it. Let's say we have a body of code which fails for an edge case. Without understanding the code too deeply, most programmers can find a way of hacking in special handling for the edge case. This process can repeat for quite some time before a codebase collapses under its own weight.
It takes significantly more brainpower to re-analyze the entire problem and come up with a coherent, elegant solution for the expanded problem definition.
And the thing is, bolting in some code that handles a single edge case most likely takes significantly less time and effort than rethinking the whole approach. And, when you're facing only a single small problem to deal with and don't have reasons to expect that more are coming, would it be justified to redesign a big pile of code just because of a minor issue?
CSS is a bad example of this, it's not like typical language code because you could have bits of css in many different files that all affect a single element. CSS is kind of like a language where mixins, monkey-patching, & aspect oriented programming are used to the extreme. Everyone who codes in this language would never go back to the main source function to modify behavior; they would instead write an aspect to patch it. Eventually nobody would know where the "main" code is anymore, all the code would be peppered in different files stomping on each other's toes.
Essentially, you could be a great developer and you could still output low quality css simply due to the way css was designed.
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.
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.
Is it not likely a bell-curve? IE: Is it not likely that there's a correlation between high line count and average quality?
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.
Actually there is. https://news.ycombinator.com/item?id=3037293
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.
My proudest commits are the ones that are never made, because I figured out how to avoid writing the code in the first place.
This is a skill, and I've been consciously working to improve it. I think the key questions are "Do I really need to write this now?" and "Is there a simpler problem I should be solving instead?"
And the beautiful thing is that we can see actual results of Bill Atkinson's philosophy. You can download the source of both MacPaint and QuickDraw from http://www.computerhistory.org/highlights/macpaint/.
It's in Pascal and 68k assembly, and I find it quite beautiful. Especially the Pascal code, as it is broken up into clear, concise functions so it is easy to understand what is going on.
Todays codecheckers would complain, that this class (sic) has far too many methods. Please break it up into smaller units ;o).
The entirety of MacPaint's Pascal code is smaller than one of the dozens of "business logic" classes in a project I worked on recently.
Well, we're making progress. Someone bothered to put "repost" in the title.
The next step is to not submit the article at all. Then we will be truly enlightened.
Seriously, who goes to a news website to read old stories? I've read this at least twice before. Why do people upvote this garbage?
An attempt at an earnest reply-- I've been reading HN for about a year (this is my first comment). Speaking as someone trying to tackle the impossibly massive field of "doing things on computers" by myself, I deeply appreciate that this isn't simply a "news website," and that the community raises issues that didn't just pop up in the last couple weeks. I've learned so much from articles that have been posted before that I never would have discovered otherwise, and I'm always a little bit disappointed when I see replies like this one. I understand concern about rapid reposts, but this was posted two years ago and then one year ago. The vitriol is completely unwarranted. Not all of us are seasoned veterans with knowledge going back decades or years or even months, no matter how much we probably wish that wasn't the case!
Seriously, who goes to a news website to read old stories?
I do, for one.
http://news.ycombinator.com/item?id=3970011
http://news.ycombinator.com/item?id=2856567
http://news.ycombinator.com/item?id=3891595
http://news.ycombinator.com/item?id=3911521
Even if it is not news for you, it's still news for other people. News is a function of novelty, not of date of occurrence.
Reading folklore.org I always think that it would be so nice to have a similar site about the development of the original iPhone and iPhone OS.
Unfortunately back then Apple was the epitome of the hacker-friendly, open culture company (waving a pirate flag on the building!) and nowadays they're the epitome of close-minded, control-freak behemoth, alas.
In software I have noticed that the best coders spend a lot of time removing code and the worst coders keep piling crud on top of crud on top of crud.
CSS seems to be really bad for this, but that might be because the frontend coders I have met are crappy. Rather than decrease the padding they'll ADD more css to move all of the elements, then they end up with !important rules everywhere.
I've been doing frontend web coding for more than 5 years now, and I have only had to use !important probably 3 or 4 times, and only them it was to overwrite things in stylesheets that we had no control over.
In software I have noticed that the best coders spend a lot of time removing code and the worst coders keep piling crud on top of crud on top of crud.
This is natural, if you think about it. Let's say we have a body of code which fails for an edge case. Without understanding the code too deeply, most programmers can find a way of hacking in special handling for the edge case. This process can repeat for quite some time before a codebase collapses under its own weight.
It takes significantly more brainpower to re-analyze the entire problem and come up with a coherent, elegant solution for the expanded problem definition.
...which inevitably doesn't happen and cost increases exponentially...
"Technical debt" is a major product killer.
And the thing is, bolting in some code that handles a single edge case most likely takes significantly less time and effort than rethinking the whole approach. And, when you're facing only a single small problem to deal with and don't have reasons to expect that more are coming, would it be justified to redesign a big pile of code just because of a minor issue?
"It depends" :-)
Bolting a tiny bit of code on to deal with an edge case, is an edge case of what I was saying.
Generally the the generalization applies
;)
CSS is a bad example of this, it's not like typical language code because you could have bits of css in many different files that all affect a single element. CSS is kind of like a language where mixins, monkey-patching, & aspect oriented programming are used to the extreme. Everyone who codes in this language would never go back to the main source function to modify behavior; they would instead write an aspect to patch it. Eventually nobody would know where the "main" code is anymore, all the code would be peppered in different files stomping on each other's toes.
Essentially, you could be a great developer and you could still output low quality css simply due to the way css was designed.
I always feel a little glow of pride when I check in a commit and see a net negative lines of code in the diff.
reminds me of Bob Jenkins' (of hash function fame) comments on his resume [1]:
IBM (1988) ... The existing code tended to shrink when I edited it. I wrote a total of minus 5000 lines of code that summer.
Oracle (1989-2006) Oracle's code (C and PL/SQL) is very good. It usually didn't shrink when I edited it.
[1] http://burtleburtle.net/bob/other/resume3.html
this was submitted yesterday under a different title, why did you repost it?
Was it? I usually see things like that. Do you have an ID so I can check? Thanks.
(pause)
I've just done a search and I can't find it. Are you sure?
http://www.hnsearch.com/search#request/all&q=folklore.or...
Doesn't seem to turn up anything. Do you remember what the other title was?
ALl I remember was that in parenthese he had (folklore) and something else. I don't know, it seems to be gone now.
I studied art in college, and one of my professors once said, "when drawing, you should use your eraser as often as your charcoal."
That's always stood out for me, and whenever I hear that Bill Atkinson story, I'm reminded of it.