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