

-2000 Lines Of Code - ColinWright
http://folklore.org/StoryView.py?project=Macintosh&story=Negative_2000_Lines_Of_Code.txt&sub=HN0

======
rpeden
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.

~~~
mironathetin
Todays codecheckers would complain, that this class (sic) has far too many
methods. Please break it up into smaller units ;o).

~~~
jcromartie
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.

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

~~~
stickfigure
_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.

~~~
TeMPOraL
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?

~~~
stickfigure
"It depends" :-)

------
pjscott
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?"

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

~~~
solox3
There is no correlation between line count and code quality.

~~~
bunderbunder
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
\- 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.

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

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

~~~
wazoox
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.

------
mm_alex
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>

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

------
voxx
this was submitted yesterday under a different title, why did you repost it?

~~~
ColinWright
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...](http://www.hnsearch.com/search#request/all&q=folklore.org&sortby=create_ts+desc)

Doesn't seem to turn up anything. Do you remember what the other title was?

~~~
voxx
ALl I remember was that in parenthese he had (folklore) and something else. I
don't know, it seems to be gone now.

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

~~~
ta12121
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?

~~~
ptgloden
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!

