

Teaching taste - akkartik
http://akkartik.name/post/teaching-taste

======
escherize
The student picking up indentation 'automatically' is a great example of pain
being an extremely useful teacher. The pain of getting lost in one's own code
leads to a desire to become more organized.

Programming a system adheres to an oral history tradition, where the First
generation has suffered the pain of some attribute (henceforth X) of their
system. So they build a certain path around it.

The second generation (like the student in the article) is told why attribute
X is avoided as a rule, however without the first-hand experience of the pain
from attribute X's characteristics meaning is lost.

Finally the third generation is told to avoid X, and can't really explain why
anymore.

------
tragic
I disagree with OP on his bullet points of what doesn't matter (and I don't
think it follows from the anecdote):

> That indentation is more than an incidental detail.

> That good programming is about following a set of rules.

> That aesthetics matter in code beyond the behavior being implemented.

I'm going to leave indentation aside for the moment, and talk about line
length. People do serious research into how line length in text layout affects
various aspects of reading: ease of comprehension, perceived ease of reading
(not the same thing, apparently[0]).

Breaking up long lines has no effect on program behaviour, but it does have an
effect on comprehension. And programming is by and large a team sport, in
which any given piece of code is read many more times than it is written.

We think of, say, four-spaces-versus-two-spaces as a matter of preference and
a source of silly holy wars. It needn't be only those things, however: on
this, I have no convenient research link, but research could be done, and I
have never noticed anyone using one-space indentation, suggesting that it
isn't a purely arbitrary choice.

So OP's story of his student seems to directly undermine his conclusions: yes,
aesthetics DO matter "beyond the behaviour being implemented", and whitespace
is more than an incidental detail if you want code to be easier to debug and
change. Following rules is hardly the worst way to get a sensible default for
code readability - it is rare that there is a set of code-style rules that
results in utterly illegible gibberish. There is always the danger of cargo-
culting, but that's life.

[0]
[http://www.tandfonline.com/doi/abs/10.1080/01449290410001715...](http://www.tandfonline.com/doi/abs/10.1080/01449290410001715714),
summarised here
[http://blog.fawny.org/2005/09/21/measures/](http://blog.fawny.org/2005/09/21/measures/)

~~~
akkartik
1\. I wasn't claiming to justify the bullet points, just pointing out that
teaching rules without justification causes "bundling" and might have
implications beyond the narrow thing you're trying to teach.

2\. Notice that I said I indent my code. I deliberately chose the phrase "not
very important" rather than "not useful". Your links seem to back me up there.
The fact that those studies on line length yield equivocal results, might it
not suggest that the _content_ of the lines has a larger impact on
comprehension? I can agree with you that a few scattered islands in the ocean
have land, and still consider you wildly misguided for choosing to explore
them rather than the huge continental landmass beyond the ocean.

3\. I think most code is utterly illegible gibberish to everyone but the
author[1][2]. This isn't directly the fault of code-style rules, but it _is_
caused by the pernicious idea that the code style rules are all you need. Now,
nobody actually thinks that, but spending a lot of time talking about
superficial details gives the mind a powerful subconscious cue.

[1] [http://akkartik.name/about](http://akkartik.name/about)

[2] [http://akkartik.name/post/readable-
bad](http://akkartik.name/post/readable-bad)

------
Luyt
Even before I took up programming, I used indentation: on my TODO lists, and
outlines of ideas. Using indentation is very obvious when you want to group
lines of text and/or express different levels of hierarchy.

