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.
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.
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?"
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.
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.
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!
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.