[baddox]

I'm not against that at all, but it doesn't really work when you're on a shared codebase with people who use spaces to align things based on the assumption of fixed-width fonts. Things like:

    hash[:foo]   = 5
    hash[:sdfkd] = "x"
    hash[:x]     = "y"

Of course, I'm against doing this anyway, because it causes issues when you want to add an even longer key to the hash.

[profsnuggles]

If you are using a decent text editor it's easy to keep things aligned. Emacs for example m-x align-regexp = will do the trick. I would assume vim, etc have similar options.

[subsection1h]

> it causes issues when you want to add an even longer key to the hash

What issues? Needing to realign the values? If so, does your text editor not include alignment commands like these:

http://www.emacswiki.org/emacs/AlignCommands

[nitrogen]

Realigning the values causes all of the lines to change in a line-by-line diff (e.g. as displayed by git diff). It also makes "git blame" less helpful, since every realigned line appears to originate from the alignment commit.

[e12e]

I agree -- but I'd think the work-around would be to do whitespace-insensitvie diffs? Which would probably be a good idea if the codebase uses indentation like this?

See eg: https://stackoverflow.com/questions/7310033/how-to-make-git-...

[jacobparker]

`git blame -w` to ignore whitespace. There are other good options (like `-M`, ignore moved lines) available in the documentation.

[alxndr]

I really wish GitHub would show me all diffs with `-w` by default, with a switch to turn it off...

[rkowalick]

Adding a query parameter of w=1 to a github page with a diff will ignore whitespace changes.

[alxndr]

Yep, but I end up sticking that parameter on to a lot of URLs, so I'd like that to happen for every time I view a diff.

[skelsey]

This is what tabs are for.

[Silhouette]

Elastic tabstops[1] are one of those things I wish was standard in the programming world, because it seems to have essentially no downside as long as tools support it.

Failing that, many text editors will provide some sort of realign command that will adjust spaces on adjacent lines so the columns line up as intended in these situations, and many diff tools and related functions like 'blame' commands in VCSes will allow you to ignore whitespace-only changes these days.

Personally, I prefer to have non-trivial code neatly lined up, despite the potential irritations when reviewing changes later. I find the advantages of highlighting patterns (and highlighting where a line didn't follow the same pattern as all the others) outweigh any practical issues where a few tools show diffs I would prefer to ignore.

I make an exception for Python, because PEP8 explicitly advises not to do this, and sometimes having a coding style that is consistent with everyone else is worth more than any of the above.

[1] http://nickgravgaard.com/elastictabstops/

[espadrine]

This algorithm sounds like it has a dreadful worst-case complexity. It can have to parse the whole file to give the intended result (eg. in the case of a dense table, when deleting a character at the end of the longest cell of a column).

It also has terrible partial results. For instance, removing the tab after `cell-missing` in the example triggers a weird alignment.

That is too bad, since the idea is bright.

PS. This is off-topic, but I cannot create a new thread on it, since it was submitted to HN six years ago and that old thread is locked: https://news.ycombinator.com/item?id=333626

[Silhouette]

FWIW, it's not that particular implementation that I'm in favour of. As you say, it has some issues.

Also, while the page I linked to was the first time I saw anyone offer a convenient name and write-up to cite, I should acknowledge that there had been discussions about using tab widths that varied by context long before that page was written. Many editors have provided related functionality where hitting tab once would automatically align your code blocks, function parameters, etc.

I suspect that for anything closer to the specific elastic tabstops idea I cited to become established, we'd need a distinct character rather than reusing ASCII spaces and tabs. This could work rather like the way various typesetting systems and DTP packages have "align to here" markers that don't necessarily introduce any extra horizontal space themselves but do indicate that consistency should be enforced across related lines.

I personally think that a standardised character like that and support for it in tools like editors and diff displays could bring several modest benefits: aside from the immediate convenience of aligning code more neatly if that's helpful, it could actually clean up a lot of whitespace-based diffs that tend to confuse tools today without necessarily having to ignore all whitespace, and of course it would improve the usefulness of proportional fonts when reading code, which I think is where we came in.

[baddox]

Would you use that in the example I gave, in the middle of the line of code? I don't quite see how that would work.