int n   = 42;
    int acc = 0;

Edit: Install http://wbond.net/sublime_packages/alignment and add this key binding `{ "keys": ["ctrl+shift+a"], "command": "alignment" }`.

Prose is obviously different, but it's probably worth considering that the only consideration for the length of a paragraph is the rules of paragraph writing, and not at all the physical length of words and sentences.

And then there's refactoring and renaming, and what that does to your artfully placed characters.

Figure out your placement and spacing rules (or better, use a canned set of rules), use them, and think about other things.

To someone who views this as a table, the above is so much more readable that it doesn't even bear thinking about. To someone who reads code the way a computer parses it (as I do), the added space can completely throw them for a loop. What the hell are you doing with n? Oh, if I look far enough, there is an assignment there.

Very likely you will see what I've written and find it incomprehensible because you have never looked at an expression the way I do. What's worse is that there isn't just 2 ways to look at it. Coding style purists usually don't realize that they are simply fooling themselves into thinking that their way of looking at something is optimal for everyone.

As someone else mentioned, the day when we can express how we want our code formatted and our editors will instantly format it that way (for everyone) can't come soon enough. But until then, it would be best to simply realize that there is no "best" way and that you should go with what the majority of the team likes, no matter what you personal preference is.

    Madonna, Rain, 3:45
    Lady Gaga, Bad Romance, 4:17
    U2, In God's Country, 3:57
    LCD Soundsystem, I Can Change, 6:31

    Madonna          Rain              3:45
    Lady Gaga        Bad Romance       4:17
    U2               In God's Country  3:57
    LCD Soundsystem  I Can Change      6:31
    

If not any idea why tables work for you sometimes and not others?

    foo        (5, 7);
    barbar        (j);
    do_stuff(6, 1, 7);

    if   (x == y) {
      ...
    }
    for  (...) {
      ...
    }
    while(...) {
      ...
    }

    int n[16] = {
      15, 17, 22, 38,203,155,  7, 10,
     255, 11, 44,  1,  0,  0,  5,227
    };

Actually, if you were really reading "the way a computer parses it", you'd ignore whitespace completely.

I write a lot of coffeescript ;-)

Joking aside, on my current project we elide the parentheses when making function calls with arguments. So:

    myfunc(foo)

    myfunc (foo) ->

    myfunc       (foo) ->

But most code that has structural isomorphism should be replaced by a loop or a function composition; repeated structural isomorphism is a redundancy that can be eliminated.

Aligning the initialization of a bunch of unrelated variables is a bit of a mixed case. Sequences of initialization are much more common in older languages, like C, that don't permit delaying the declaration. I don't have a strong opinion either way. If the data being initialized is structural, a tabular format should definitely be used, if it isn't fighting the tool (some IDEs etc. autoformat, or lint complains on unnecessary whitespace). If data is not structural and the variables aren't strongly related to one another, I don't see a good argument in favour of alignment, particularly when variable names can have wildly different lengths, e.g.:

    source                            = 10;
    timeout                           = 20;
    wait_count                        = 30;
    ch                                = 0;
    accumulator                       = 40;
    access_denied_retry_callback_list = [];

    source = 10;
    timeout = 20;
    wait_count = 30;
    ch = 0;
    accumulator = 40;
    access_denied_retry_callback_list = [];

    source      = 10;
    timeout     = 20;
    wait_count  = 30;
    ch          = 0;
    accumulator = 40;
    
    access_denied_retry_callback_list = [];

Whitespace edits are the code equivalence of wikipedia formatting changes to increase the number of articles you've worked on without actually contributing anything.

Also, if you think that is easier to read you are actually setting yourself up by being deceived by formatting because you'll be skipping bits based on assuming you know what they say. Those are hard lessons to learn but the best way to understand a new piece of code that you're reading is not to read it like a book but like a machine, with a pencil and a notepad tracing the values of the variables as you execute the code in your head (or on the paper if it gets complex). You don't need to run the whole program that way, just the sections that you feel are hard to understand.

It does not logically follow from the code being "cleaner" that it is easier to read. Having to scan across a field of whitespace to get to the number makes it harder to read and easier to make mistakes. Having the indentation of the number be unrelated to the length of the variable name adds another aspect that makes it harder to read and easier to make mistakes.

It's also harder to edit, which makes you do fewer edits that make the code materially better.

    parseModifier : String -> Outcome Modifier
    parseModifier s = case s of
      "shift"   -> Ok Shift
      "ctrl"    -> Ok Ctrl
      "alt"     -> Ok Alt
      "meta"    -> Ok Meta
      "command" -> Ok Meta
      "windows" -> Ok Meta
      x         -> Err <| "Unknown modifier: " ++ x

    parseModifier : String -> Outcome Modifier
    parseModifier s = case s of
      "shift" -> Ok Shift
      "ctrl" -> Ok Ctrl
      "alt" -> Ok Alt
      "meta" -> Ok Meta
      "command" -> Ok Meta
      "windows" -> Ok Meta
      x -> Err <| "Unknown modifier: " ++ x

But ideally this is something that should be decided by each developer's personal editor config, like tab widths for indentation.

    git diff -w

Also, note that you can do the same in github:

Append ?w=1 to the url for the diff viewer and you'll get the whitespace ignored version.

Tracking bugs through changesets is hard enough, no need to make it harder on purpose.

And yes, I know about git diff -w, but 1. not all tools built around git support it and 2. not everybody uses git.

The whole point of coding style is that someone else will have to read and maintain your code. If you step away from your code for even a month, it's almost like reading someone else's code when you come back to it. If you're writing code that will never be seen again, and simply has to work once, you don't need any style whatsoever. But that's not very common.

I think the biggest motivator is having to debug/port someone else's code full of magic numbers, short variables, long functions, global variables, and no comments.

Yes, you have worse problems than ambiguous abbreviations :) That doesn't make the abbreviations okay, though.

Not every shorten the same word the same way, not even yourself next year.