Geek Blight

If you want to discuss just for the sake of discussing about something with your fellow programmers, just ask if tab characters are a better way of indenting code than spaces. People will start pointing out the pros and cons of each method, and can easily become very passionate about the method they use and enter a quite heated discussion on who is right and who is wrong, which method is more practical and which one is not, which is The Right Thing and why the followers of other methods should be shot down.

When you work alone it doesn’t matter. You cook it, you eat it. The problem comes when you have to collaborate with other people and you need to view and edit their code, and not everybody uses the same editor with the same settings.

Back in the old days everybody edited their code indenting with tab characters, which is typically represented as an 8-spaces wide gap. But in many modern languages, that space is just too much. The language itself makes the typical indentation level deeper, and the convention today is to use longer variable names, package names, method names, package and namespace prefixes, etc. You end up with some pretty long, yet very simple, lines. So an 8-spaces wide gap is too wide. Many modern editors, then, default to not using tab characters and indent, unless you specify otherwise, with 4 space characters. Indentation is usually a matter of appearance in many languages. In others, however, it’s very important. That’s the case of Python, which uses whitespace as a form of identifying blocks of code. This debate is more critical for those languages.

Proponents of using spaces to indent always mention that if you indent your code with spaces, it will display exactly as you view it no matter which editor you’re using. If, on top of that, you set the indentation width to 4 spaces as is the default in many editors, your chances of creating a conflict in the indentation style are smaller, so it’s a friendly way of indenting code, and a de-facto standard. On top of that, they will tell you to avoid using the tab character at all when working with Python, and make your editor replace everything with spaces always. This way you won’t be able to create invisible syntax errors by mistake. You can extend this practice to any other language, for convenience.

Proponents of using tabs will argue that using tabs is more flexible, because most if not all mainstream editors let you indent with tab characters and adjust the width of the displayed gap. So if Alice likes a 4-spaces wide gap, Bob likes 8-spaces wide gaps and Charlie likes 2-spaces wide gaps, they can all indent their code using tabs and adjust their editor settings. Code written by any of them will display in the preferred style of any other when they work on it. So, yes, those are not the default settings in many editors, but they’ll argue that this method is more friendly in the long run. Furthermore, they’ll tell you to interpret the tab character as a semantical mark of "deeper indentation level". In the same way you can create a webpage specifying which blocks of contents you have and then use CSS to define how those blocks are to be represented, the tab character acts as a semantic marker whose appearance can be tuned in the editor settings.

Both sides are right in what they say, so that’s why it all degenerates into flames. You will have to choose one side yourself. For the record, I choose tab characters, as in my opinion the reasons on that side are stronger. Vim lets you choose the tab size (:set ts=[your preferred width]). I don’t know about Emacs but it would be a severe failure in its customizability if it didn’t let you. Kwrite lets you adjust the tab size too, and with it Kate and KDevelop. Even Dev-Cpp for Windows lets you indent with tabs and tune the tab width. I edit code with Vim usually, and avoid using spaces for indentation. It’s worth mentioning, though, that spaces are the preferred official way of indenting Python code and this is also reflected in many code style guides from different sources and entities.