Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
The coding standards for the code hosted in drupal.org suggest to use two spaces to indent the code; other sites suggest to use tabs to indent the code.
What is the proper indentation character for everything, and in every situation? Please explain the answer you give.
Spaces
A tab could be a different number of columns depending on your environment, but a space is always one column.
In terms of how many spaces (or tabs) constitutes indentation, it's more important to be consistent throughout your code than to use any specific tab stop value.
Tabs
Now, of course, consistency matters more than either one, and a good IDE makes the differences negligible. That said, the point of this thread is to be a holy war, so:
I prefer tabs:
Use tabs to indent the start of the line, one tab per indent level, and let everyone pick how wide they want that to be.
Use spaces if you're lining up characters within a line, so they always line up regardless of tab size.
And find and punch all the early software authors who let this stupid thing become an issue in the first place.
(Seriously, why is this even something that's discussed? Next you'll be telling me you also want to use multiple characters for line breaks!)
Tabs
Spaces should be used where tabs are completely useless.
Even for aligning parameters and comments, tabs still work better.
All of the arguments for tabs are great in theory. But...
In theory, practice and theory are the same. In practice, they are not.
Yes, with tabs you can decide your indentation level. And yes, you can use a combination of tabs and spaces to align things. And in an ideal world it would
In reality, you can't see the difference between spaces and tabs, they always seem to get mixed up when moving code around, and viewing the code in another program that has tabs set to 8 columns is a nuisance.
I used to use tabs. Then I started to work as part of a team and share code. I quickly became a proponent of spaces. So while I can sympathize with the utopia of tabs, I can't imagine not using spaces.
public: in C++ class declarations so they look prettier (especially with nested classes).
Some relevant opinions that may be of interest:
I. absolutely. hate. 4. spaces.
Why? Mainly because I'm tired of navigating my code with a keyboard and having to constantly hit left left left left to go over one indentation. This was born out of early versions of Notepad++ and even plain Windows notepad where there was no such thing as a format button. I had so many issues when people would only use 3 when I had used 4 everywhere else among other things.
The other reason is that the tab character exist specifically for indentation, and was only later adopted for navigation. Why are we doing space space space space when a simple tab would work? Why should IDE's have to deal with 2-5 spaced code and format correctly when a simple tab and a preference option would work?
Unfortunately I'm the minority.
w and b (or e and ge) to skip through whitespace and tokens :P
Sep 15, 2010 at 3:45
I personally like to use tabs in everything, since each developer can control the amount of indentation per tab. That way you get flexibility in display.
That being said, I usually mimic whatever coding style is in the file to start with (since I spend a lot of time doing maintenance work).
I do not think that there is such thing as proper indentation (at least not without minor war).
Personally I like four spaces. They enable me to read code much faster and they look same in every editor - even Vi.
softtabstop option and the retab and retab! commands.
Spaces, because when you align comments to the right of code, or function parameter lists, or complex multiline expressions, or things of that nature, you want your beautiful work to appear right for everyone. If you use tabs and allow people to set their tabstops differently, they will break alignment for all but the simplest cases of code indenting.
Besides, it's blatantly obvious that everyone in the world should be using vim, which makes it trivial to indent, unindent, and navigate through "tab stops" even in space-indented files.
Tabs are the natural and orthodox choice, as they are by definition used for indentation.
Unfortunately, tabs are unevenly implemented, so the only real world solution is 4 spaces.
You obviously need a combination approach.
If you're sharing code with other developers, you need to standardize, and since that's impossible (koff koff), you need to make everyone do four spaces.
Then you need an editor that's smart enough not to be stupid about that, to know that it should treat a line with four spaces at the front of it like it's indented. Any modern IDE or programmers' editor can auto-flow code with spaces instead of tabs.
Why can't someone implement this:
Everyone is happy as they all see their 'own' format
Is that so difficult?
Spaces or Tabs - What Atwood really says is pick one thing and be consistent in your project. The only holy grail of code formatting is to make certain that its consistent so that the psychopath who maintains your code after you doesn't feel compelled to remedy the situation permanently.
That said, if you're working in Python or any other language where whitespace is an actual programming construct I can't imagine using tabs.
I'm a 4 space kind of guy, tabs just aren't consistent.
Apparently tabs mess stuff up in Delphi so I don't use tabs in Delphi.
However I do everything else using Emacs and always use tabs because my tabs go exactly where I want them to go.
The answer is that there can be no single proper indentation character for every situation. Formatting using characters is inflexible and can cause conflict when different styles are used within a team.
The only method to format code flawlessly and flexibly with different formatting styles is to do it virtually, that is, without any indentation characters. The only code editor I know that supports this though is the one used in the sample below:
To demonstrate virtual formatting, the screenshot below is from an XSLT editor* that uses this indentation method (there's also a short video here). Every character in the XSLT has been highlighted in yellow, for illustrative purposes, to allow the only tab or space characters in the content to be seen clearly. The code indentation is handled by the editor's rendering system adjusting the left margin (which has a white background).
The only leading space characters precede the Books lines, because this is literal text content, not code, these space characters must be preserved.
With virtual formatting you choose the indentation width to suit the environment and indentation style without affecting any characters in the source file. You can even set the indentation width to 0, if you need a flattened view of the code as shown below:
To contrast this with space character formatting, the same XSLT opened in an editor without virtual formatting is transformed by that editor's auto-formatter to this:
The larger blank yellow blocks in the screenshot above clearly show the space characters added by the formatter of the conventional editor. Unfortunately, these now can't be distinguished from real content so the XSLT would have to be modified to correct this issue.
Summary
XSLT is possibly an extreme case, but this principle holds true for many programming languages: Characters should be used for content and an alternative method sought when it comes to formatting.
**Disclosure: The XSLT Editor with virtual formatting was developed by my own company*
Not mentioned until now: There are languages (Python, Haskell) where indentation matters. But 1 character counts as 1 character, be it a space or a tab so the indentation seen by the compiler may not be the same one you see on the screen if you use tabs.
Therefore, in languages like Haskell, spaces are a must. In Makefiles, TABS are a must. In all others, it's a matter of personal taste and nowadays not a great deal - every decent editor has a "(leading) tabs to spaces" and "(leading) spaces to tabs" command.
I used to use spaces, but I've been using tabs lately purely because that's what Eclipse was set to when I finally noticed. All of the other developers on my team use Eclipse, so it made sense to standardise on tabs when we realised we'd already been using them for ages and there was no reason to bother changing to spaces. I've been surprised by how much of a non-issue it has been.
Setting the displayed tab size to 3 or 5 characters in your IDE greatly simplifies distinguishing between code sections that are indented by spaces (almost always 4 these days) and those that are indented by tab.
Plenty of arguments have been given already, but nobody mentioned where we could be headed in the future.
Tabs nor spaces!
Ideally code should be considered data, and not be stored in any specific text formatting. Any developer can apply his own preferred view. Furthermore, this view shouldn't be limited to just text, but can include tables, color pickers and mathematical formulas.
This idea isn't too far-fetched. It was JetBrain's Language Oriented Programming editor Meta Programming System (MPS) which first made me realize this resolves the entire discussion, simultaneously adding a lot of extra possibilities. (Yes this is possible with editor plugins, but working on text directly adds so many unnecessary complexities, as opposed to the approach MPS takes.)
As opposed to tabs and spaces, there are little disadvantages which can be mentioned for working directly on abstract syntax trees. All that is needed is for the technology to mature to a commercially viable product. The first signs of this are showing up. Largely built upon MPS, a commercial actionscript editor, Realaxy was created.
I'd love to see one of the big players jump on the concept of this technology and see what happens!
Neither is better, neither is worse. The only important thing is to be consistent.
If you are a team of one, pick whatever you personally like. Consider what the default behavior of your favorite editor, but pick whatever you like.
If you are on a team, do what the team does. Period.
In my various jobs I've used two spaces, four spaces, eight spaces, tabs, spaces-and-tabs, I think I may have also used one space. I tell my editor what to do then I don't think about it again, the editor works out the details.
The only other thing is to make sure you pick a smart editor. Emacs or vi? Now that's a holy war I'm willing to fight :-)