Hacker News Reader

Comment by gwbas1c | Hacker News Reader

I used to agree with that, until I read this article. I would always use the IDE's default and "not care" as long as the code was consistent.

The problem with tabs is that they render as different widths in different contexts. For example, Visual Studio shows them as 5 spaces, but Github shows them as 8.

Puts me firmly in the spaces camp now.

View on HN

> The problem with tabs is that they render as different widths in different contexts

The funny thing is that this is why I prefer them. It means I control how indents render rather than the person who wrote the code.

I would agree, except that only deals with the left hand side of the code. We are also making decisions on the right hand side of the code to deal with lime width as well which only really works if all developers have the same tab size.

Nowadays I just chuck format on save on all the code I deal with so I don't have to deal with any of this stuff anymore.

If we take this to its longer conclusion though, it would be pretty good if our tooling supporting a difference between the view (using your own preferences) and storage (consistent code for committing to git or whatever).

What? If you have lines that are too wide, you can

1. Change the tab width in your IDE 2. Turn on line-wrapping

1. This problem is introduced by increasing the tab width, so this solution is basically "don't do that". 2. Line wrapping on something like C where you have braces is okay, but not with something like Python where the code now looks wrong.

I'm in the spaces camp, but I was musing about this for the tabs camp because wanting to adjust the indentation seems reasonable.

(My "favourite" convention was Luajit where the convention was: 2 spaces, until we got to 8 spaces, in which case tab.)

Yep, that's why line-wrapping is #2. I can see why it'd be less acceptable for some languages.

> I used to agree with that, until I read this article. I would always use the IDE's default and "not care" as long as the code was consistent.

The problem is that everyone touching the project can and often does have different defaults. If you work on a professional setting, specially in legacy projects, you are bound to touch files where your changes comprise mainly of whitespace changes.

That's why "clean up tabbing" projects happen.

This is an oft-repeated and utterly bogus argument. You can simply change how many spaces a tab is in your own IDE. And in decades of programming in IDEs from Borland to Visual C++ (since there were separate 16- and 32-bit versions) to Xcode... I've never seen one default to five spaces. Four spaces is, by far, the most common.

People who don't understand tabs are akin to those who don't understand styles: Doomed to laboriously dick around with formatting, and make work for everyone else.

> I would always use the IDE's default and "not care" as long as the code was consistent.

I mean, "just use the IDE's default" isn't really agreeing, unless that's what your entire organization does too, and you all use the same IDE :)

Pretty much everywhere I've worked everyone uses the same IDE. When someone doesn't, we make sure they know we aren't going to make too many accommodations for them.

> Pretty much everywhere I've worked everyone uses the same IDE.

FWIW, none of the places where I've worked has everyone used the same IDE (or an IDE at all, personally I use nvim so :shrug: ). Fun how the world is different for everyone :)

Reply on news.ycombinator.com