I'm curious, would you prefer your favorite music player list things like this

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

vs

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

I'm not questioning that you find columnized code hard to read I'm just wondering would that apply to all forms of info? Your email list with time, name, subject. Your bank statement with data, biller, amount?

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

I'm not the parent, but as someone who also doesn't prefer aligning variable initialisers I can say the reason is that declaring variables and initialising them is not something I see as being tabular --- they're just a sequence of statements, and I wouldn't align them just like I wouldn't do this with a series of function calls:

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

or this with flow control statements:

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

Things like array initialisers, however, I do align.

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

To someone who reads code the way a computer parses it (as I do), the added space can completely throw them for a loop.

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

> 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) ->

is an important difference when I'm reading the code. If you write:

    myfunc       (foo) ->

it means the same thing, but it completely throws me for a loop because I have to look ahead too far. So you are right, I don't look at it the way the interpreter does. I'm inferior and can only handle a grammar with a single look ahead ;-)

Tables require sequences of structurally isomorphic operations. Columnized code can work very well for matrix calculations, for example.

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 = [];

I find this substantially harder to read (see name to value and vice versa) than non-tabulated initialization.

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

To be fair, the readability problem can be solved like this:

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

(Still, it's not tabular data, so it has no business being a table.)

That's actual tabular data though. The variables `n` and `acc` are not the same type of thing; they don't belong in the same table. (Unless you were making a table called "local variables", but that is already obvious or redundant.)