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.
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
This code in their old column-aligned style is actually one line taller than the indentation style they recently switched to.
Cannot you just have your editor do that for you?
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.Of course, if you already have made one of these two jumps, it should be a no-brainer to make the other one as well.
Proportional fonts are different. Anyone can use them without interfering with readability regardless of the fonts and editors that others use. If you look at my code, you will never know whether I wrote it in a proportional font or a monospaced font.
It is not quite as bad as you make it sound.
While editors which haven't yet implemented the elastic tabstops mechanism may not align some text properly in files where tabs were used with elastic tabstops, the problem isn't that bad. All leading tabs (indentation) will be okay, and the chances of text not aligning correctly diminishes as the width between tabstops increases.
Most things line up perfectly fine i IntelliJ.
I have had someone on my team with an itch for lining up variable assignment. That was the one thing that looked off.
int abc = 3
int defg = 4
int bigTestVaribale = 6Nevertheless, for teams that insist, the auto code formatter makes it look ‘nice’ for them.
Personally, I think vertical alignment apart from indentation is a mistake for more than these reasons. It implies a structure where there is none.