Typography is a subtle and tricky thing. What seems “better” may actually provide misleading cues.
For example, consider the alignment in the following, improved snippet from the blog post:
var x = shape.left(),
y = shape.right(),
numSides = shape.sides();
It may be “better” typographically, but it also suggests a false parallelism.
The eye can't help but interpret closely packed things as groups. So the subliminal cue presented by the formatting above is that there is a parallel assignment from the group of expressions on the right to the group of variables on the left. That is, at some level the eye can't help but see the code above as
{ e }
{ v } { x }
var { a } = { p } ;
{ r } { r }
{ s } { s }
But the evaluation and assignment are not parallel! They are sequential. The difference may not matter in this example, but it's easy to imagine this kind of formatting applied to examples where it would.
The less-formatted original version below actually represents the reality more faithfully because its shape does not suggest parallelism:
var x = shape.left(),
y = shape.right(),
numSides = shape.sides();
Typography doesn't address /what/ should be written but rather /how/ it should be presented to make what was written as readable as possible.
I think this hints at what you're saying, though the author's presentation style may imply that his is the way formatting needs to be done.
"What was written" is analogous to "what the author meant". If they author makes the assumption that those operations may be executed in parallel, irregardless of order, then the exampled typesetting may be appropriate. "Better" typography shouldn't imply that it looks pretty, as in artistic. It should be more readable, without getting in the way of conveying the author's intent. It should aid the reader in reading, and in reading, arriving at the author's meaning.
As with anything, I don't think blindly adhering to example is a good idea; this case is no different.
You're dead-on that typography is subtle and tricky!
The point I was trying to make, however, is that since the example code is JavaScript, the reality is that a statement like that will always result in sequential evaluation and binding and, therefore, a typographical treatment that suggests otherwise will provide misleading cues always.
The author's intent doesn't matter at that point. The typographical treatment has already reached the reader's eyeballs.
If the language were Haskell, however, the align-on-equals treatment would actually communicate the truth. For example, the following code means exactly what its visual presentation suggests it means (see [1]):
let x = y + 1
y = foo 0
foo i = max 0 (i - 1)
in ...
So this treatment adds clarity, not takes it away.
The kind of people that line up their assignments and other syntax elements of the same sort are the ones that prefer justified text, even in inappropriate cases. It's annoying.
You also end up with "floaters", where if in this case `numSides` is removed, x and y assignments will have a needless number of spaces. These can be corrected, but you'll also inherit "blame" for the change, which is misinformation.
Keep them tight, learn to read code that way. Code is not ASCII art.
Also, when you introduce a new variable in such a block of initialisers, and it is longer than the other variables, you have to pad all the other declarations with spaces just to keep them aligned... what a waste of time. Apart from that, it also generates 'false' diffs with source code control systems which are configured to be sensitive to whitespace.
Comments
Typography is a subtle and tricky thing. What seems “better” may actually provide misleading cues.
For example, consider the alignment in the following, improved snippet from the blog post:
It may be “better” typographically, but it also suggests a false parallelism.The eye can't help but interpret closely packed things as groups. So the subliminal cue presented by the formatting above is that there is a parallel assignment from the group of expressions on the right to the group of variables on the left. That is, at some level the eye can't help but see the code above as
But the evaluation and assignment are not parallel! They are sequential. The difference may not matter in this example, but it's easy to imagine this kind of formatting applied to examples where it would.The less-formatted original version below actually represents the reality more faithfully because its shape does not suggest parallelism:
It looks more like a sequence, which it is.Indeed, typography is a subtle and tricky thing.
Typography doesn't address /what/ should be written but rather /how/ it should be presented to make what was written as readable as possible.
I think this hints at what you're saying, though the author's presentation style may imply that his is the way formatting needs to be done.
"What was written" is analogous to "what the author meant". If they author makes the assumption that those operations may be executed in parallel, irregardless of order, then the exampled typesetting may be appropriate. "Better" typography shouldn't imply that it looks pretty, as in artistic. It should be more readable, without getting in the way of conveying the author's intent. It should aid the reader in reading, and in reading, arriving at the author's meaning.
As with anything, I don't think blindly adhering to example is a good idea; this case is no different.
You're dead-on that typography is subtle and tricky!
The point I was trying to make, however, is that since the example code is JavaScript, the reality is that a statement like that will always result in sequential evaluation and binding and, therefore, a typographical treatment that suggests otherwise will provide misleading cues always.
The author's intent doesn't matter at that point. The typographical treatment has already reached the reader's eyeballs.
If the language were Haskell, however, the align-on-equals treatment would actually communicate the truth. For example, the following code means exactly what its visual presentation suggests it means (see [1]):
So this treatment adds clarity, not takes it away.[1] http://www.haskell.org/onlinereport/exps.html#sect3.12
The kind of people that line up their assignments and other syntax elements of the same sort are the ones that prefer justified text, even in inappropriate cases. It's annoying.
You also end up with "floaters", where if in this case `numSides` is removed, x and y assignments will have a needless number of spaces. These can be corrected, but you'll also inherit "blame" for the change, which is misinformation.
Keep them tight, learn to read code that way. Code is not ASCII art.
Also, when you introduce a new variable in such a block of initialisers, and it is longer than the other variables, you have to pad all the other declarations with spaces just to keep them aligned... what a waste of time. Apart from that, it also generates 'false' diffs with source code control systems which are configured to be sensitive to whitespace.