5 ms·
> Curious. How do you line things up? I don't! :-) I spent many years lining things up. I would write code like this: foobar(firstArg, secondArg,
by Stratoscope 8y ago
> Curious. How do you line things up?
I don't! :-)
I spent many years lining things up. I would write code like this:
foobar(firstArg,
secondArg,
thirdArg);
(For the sake of discussion, assume that those arguments were too long to just put it all on one line, so you would naturally want to use multiple lines.)
Then when I realized that 'foobar' wasn't such a good name, I had to re-align all the code:
doTheRealThing(firstArg,
secondArg,
thirdArg);
At some point, maybe 20 years ago, I got really tired of this.
So I thought, "what if I just use indentation instead of trying to line things up in columns?" Which led to this:
foobar(
firstArg,
secondArg,
thirdArg
);
And when I renamed the function, I didn't have to move everything around any more:
doTheRealThing(
firstArg,
secondArg,
thirdArg
);
Instead of every line changing, only one line changed. [1]
After I adopted this style, I noticed that the code editor I was using at the time supported proportional fonts, so I got curious and tried one - I think it was Verdana.
And sure enough, the code was just as readable as it was before.
If you don't line things up in columns but instead just use indentation, then a proportional font works just as well as monospaced.
[1] Some will say "just ignore whitespace in your VCS diffs, and this won't be a problem." But I want to know about whitespace changes, just like I want to know about any other change.
- int_19h 8y agoNot a fan of proportional fonts for coding, but the point about refactoring affecting indentation is well worth reiterating. If you have ever dug through source control history, you know that there's value in not touching the lines unnecessarily. Unfortunately, most common coding styles that advocate lining things up do this wrong, such that a single rename can affect several times as many lines that are completely unrelated.
- Fellshard 8y agoThis does force you into a style where lists of indented things require a new line - not necessarily bad, just an observable side effect, and can cause problems if you share a codebase that maintains a different style.
- Stratoscope 8y agoVery true, if you are working on an existing codebase, you ought to follow whatever style it uses. Interestingly, one of the reasons sometimes cited for using alignment is that it reduces the number of lines of code needed for a statement or expression. But as often as not, I've seen that backfire because the code gets pushed farther and farther to the right, eventually resulting in more lines of text instead of fewer. I posted an example from the Rust/Servo code in another comment: https://news.ycombinator.com/item?id=18962177 https://news.ycombinator.com/item?id=18962177 This code in their old column-aligned style is actually one line taller than the indentation style they recently switched to.
- ethelward 8y ago> I had to re-align all the code: Cannot you just have your editor do that for you?
- Stratoscope 8y agoIt was about 25 years ago that I stopped using alignment, and the editors I was using didn't have that kind of auto-formatting. But there was more to it: I realized that I didn't like column alignment any more. It didn't make the code any more readable, and in many cases it made it less readable. A more recent example of a group that abandoned alignment is the Rust and Servo teams at Mozilla. Their code style used to look like this: let mut rewrites = try_opt!(subexpr_list.iter() .rev() .map(|e| { rewrite_chain_expr(e, total_span, context, max_width, indent) }) .collect::<Option<Vec<_>>>()); A year or so ago they changed to a purely indentation-based style: let mut rewrites = try_opt!( subexpr_list .iter() .rev() .map( |e| { rewrite_chain_expr( e, total_span, context, max_width, indent ) }) .collect::<Option<Vec<_>>>() ); They found this style to have advantages over alignment, perhaps for some of the same reasons that I prefer it.