[edent]

Because I find it really handy to quickly, and visually, check the sanity / logic of something.

In your example, it's really easy to run your eyes down a column and see that one of those values is radically different from the others.

As a trivial example:

    int robert_age = 32;
    int annalouise_age = 25;
    int bob_age = 250;
    int dorothy_age = 56;

I find easier to read as:

    int robert_age     = 32;
    int annalouise_age = 25;
    int bob_age        = 250;
    int dorothy_age    = 56;

Coding styles are about readability and usability. The columns metaphor works well for some categories of data - that's why spreadsheets are so popular.

[coldpie]

This is true if you never change your code. But as soon as I have to add

  int rumpelstiltskin_age = 202;

to your code, I already want to throw you out the window for the work I have to do and the diff I have to ruin to keep your "pretty" formatting. Just don't bother.

[andreasvc]

This ruins the readability and usability of your diffs. Say you need to quickly track down a major bug due to a change in a single constant. With horizontal alignment, the diff might contain any number of changed lines, obscuring the crucial change. There are workarounds that ignore whitespace and word-based diffs, but it's just not worth the trouble IMHO.

[Sir_Cmpwn]

Is this really so bad?

https://gist.github.com/SirCmpwn/540c5fc115e9f65bfa3b

[andreasvc]

The problem I was alluding to occurs when a change causes the amount of alignment spaces to change, which then affects all the lines that have been aligned. Without alignment, the diff would be limited to just the code that was changed.

[Dewie]

We should adjust our code and text to `diff`, rather than adjusting our tools to our code and text?

[scrollaway]

While I agree diff should be adjusted to accomodate for whitespace diffs more easily by default (it can do that with some options), it's not just a burden on the reviewer. It is also a burden on the programmer.

If you have, say, 50 lines of assignment and you align all the values to the largest one, adding one forces you to update 50 lines. I've been faced with those very situations and that is when I understood how important it is not to align values like that.

[Dewie]

I don't why the committer can't leave a message like:

> Formatting change. Use `wdiff` to confirm that changes are just stylistic

The reviewer runs `wdiff` and confirms that the commit is just a formatting change. If the language is not layout-aware, then he will know that none of the changes are "semantic". Now he can look over the changed lines themselves (not necessarily with `diff`; just looking at the changed lines themselves) and see if the change is worth it/in line with the project.

PS: Maybe there should be a "column diff", something that checks that one file uses the same alignment as another file. I'm not able to show it here since HN will truncate spaces between words ( ;) ), but the point is to check if two files uses the same alignment, for example that in

> var v = 12

the next variable declaration, the numbers line up. I don't know if that is worth it, and the check would only be valid for some parts of the files.

[andreasvc]

Indeed, because adjusting version control system to parse ever language under the sun is not a good idea, and that would be required to properly identify strictly formatting-related changes.