Hacker News Reader

Comment by kleiba | Hacker News Reader

A standard argument against aligning multiple similar lines of declarations as a table is that you constantly need to re-align when you add/remove declarations. One implication is that source diffs become larger than necessary as they will now include lines that haven't actually changed content-wise, only layout-wise.

View on HN

In my younger years, I was extremely meticulous about tabulating anything in my code that was remotely tabular, but these days I pay less attention to that. Constantly re-aligning is a pain, as you mentioned. Another thing I've found is that it forces you to spend brainpower on decisions that are ultimately pointless. For instance, if the code is mostly tabular, but one line has an extra column, what do you do? Stick that column into an existing column? Add another column that will look weird with that one entry hanging? Etc.

Another really irritating result of lining everything up just so is that when you do a search+replace on a bunch of code, and change the length of an identifier. Suddenly you've screwed up the formatting on a bunch of tables without even knowing it! This is especially annoying with doing a search+replace across multiple files, with lots of code.

That's not to say that lining things up sometimes is a bad thing, particularly when you really have a table (e.g. initializing a big array of structs). Sometimes having things lined up makes it easier to edit later (e.g. using Vim's visual mode). But I'd say that 90% of the time, it's a waste of effort that could be spent, say, making your code actually work better, rather than look better.

In emacs, one can take out the drudgery of manually aligning and realigning your variables in tabular fashion using the align commands[1].

In certain revision control systems, one doesn't keep differences, but whole objects, so the point is moot there unless you have some serious bandwidth concerns.

[1] http://www.emacswiki.org/emacs/AlignCommands

It's not only about bandwidth concerns, it's more about making commit diffs readable. If you have ten lines of tabular assignments and you changed the sixth, but that made you realign everything, then you'll see 10 green lines + 10 pink lines in your commit diff, even though you should only see two lines in total.

Unless you have the option to blend out whitespace-only changes, e.g. https://github.com/blog/967-github-secrets

Have you checked uncrustify? It doesn't do all the work necessary for the tabular alignment illustrated in the article but it does great part of it. I personally use it with a keyboard shortcut to fix the selection of the code I just wrote or edite. In this way I'm faster because I skip most of the white space characters.

http://uncrustify.sourceforge.net/

Code is read many more times than it's written. Re-aligning isn't really time consuming.

Actually, many open source projects explicitly forbid vertical alignment as it becomes an obstacle for patch review.

I'm quite disappointed the article doesn't mention that.

Reply on news.ycombinator.com