Hacker News Reader

Comment by th0br0 | Hacker News Reader

Tab width can vary between editors, i.e. do a "set shiftwidth=8" in vim, and it'll be 8 spaces. Spaces are more constant.r

View on HN

I have to admit I always thought of that as an advantage of tabs, since they allow the viewer to set how much to indent the code, and doesn't force anyone to adapt to someone else's preferred style. I like it when a tab = 4 spaces, but you like it when a tab = 2 spaces. Cool, just set your editor accordingly.

Unfortunately, it also means that if the viewer hasn't or can't set the tab width, it may look awful. GitHub was using 8 spaces per tab by default, and my code looked ridiculous. Now GitHub checks .editorconfig for a default tab width, but it didn't used to.

It's certainly some progress that GitHub now follows .editorconfig! But now that they have the ability to render tabs with different numbers of spaces, I wish they could have changed the default to four spaces while they were at it. Aside from the Linux kernel, not too many people really like eight-column tabs.

I've always omitted the indent_size and tab_width settings from my .editorconfig files that specified tabs, because I wanted to let people view the code in their preferred default indentation size instead of one I specified.

(As I've mentioned too many times in this thread, I follow an indentation-only style with no column alignment, so you can view the code at any tab width without breaking the formatting.)

Now, just to make GitHub give a reasonable code listing, I'm having to add indent_size=4 to all my .editorconfig files. That's not a terrible thing, but I really would prefer to leave the choice up to the viewer instead of forcing 4-character tabs.

Isn't that the whole point of tabs? So everyone can have their own width preference without going mad with git merges.

I thought that was a reason _for_ tabs, so everybody can have their own indent size.

Reply on news.ycombinator.com