Tabs vs Spaces
When coding, should we use spaces or tabs to indent our code. Flame on... ;-)
Only kidding, my aim here is to calmly explain the pros and cons of both views, and to dismiss false notions in both camps.
Let's tackle the simplest arguments first, which IMHO, both camps should agree on :
- Tab characters should never appear in the middle of a line of code.
- Using spaces doesn't mean using the space-bar (use the Tab to indent code).
- Mixing spaces and tab characters within a single file is not a good.
- Tabulating text is a waste of time. i.e. we shouldn't strive for each = , and : to be aligned with each other.
- Using spaces is no harder or easier than using tab-characters.
This last point is important, and IMHO, a major cause of contention/confusion, and for good reasons.
All Editors are Configured Incorrectly out-of-the-box
When I hit the Tab key, my code is indented. When I hit Shift-Tab it is un-indented. Alas, that isn't the default behaviour of any text editor I know.
For some reason (probably a historical hang-up), hitting the tab key with nothing selected, mid-line does not indent code. Instead, it inserts spaces/a tab character. IMHO, this is bad. Thinking about it, they probably have this default for people who tabulate their text. Don't! (see point 4 above).
See Tab and Shift+Tab to see how to set up IntelliJ to make the Tab key always indent code.
There's Little to Argue About
When I configure my editor "correctly", it makes no difference how indentations are encoded. The keystrokes I perform are identical regardless of whether I'm using tab characters or spaces.
If your fingers have to touch different keys depending on how indentations are encoded, the problem isn't with the encoding. The problem lies in your editor.
So now we are left with how the code appears on the screen.
The Key Disagreements
Here's the pros and cons as I see them.
Tab Characters Pros
Each developer can choose their own indentation size preference. So I can view a tabbed file, using my preference of 4 columns per indent, and my colleague could choose 2, or 8. The file doesn't need to be changed to suit our own preferences.
Note, we can set up our IDE to have different indentation sizes for each file type. I personally like 2 columns for languages with deep levels of indentation, and 4 columns everywhere else.
Tab Character Cons
Source code appears in lots of places other than our text editors.
Web sites, emails, books, presentations, bug tracking software...
Your personal indentation size isn't respected here.
In fact, some of these places don't handle tab characters correctly. I've seen numerous web pages where tab characters are silently ignored.
Have you tried pasting tabbed code into an email? It doesn't work correctly using gmail. <sigh>
But let's ignore that, and assume tabs are supported.
Each of these "other" places has to make a single choice for the size of a tab character. Historically, there was a standard tab size, and that value was 8. I've never met a programmer who used such a large indent. Therefore all of these places has to disregard the historical standard if they want acceptable output.
Spaces Pros
Spaces work everywhere (i.e. the exact opposite of Tab Character Cons).
Spaces Cons
It is easy to mis-align by a single column, e.g. start on column 5, when it should be 4.
If you encode indentation with spaces, then you are imposing your preference on everyone else.
As an aside, this could be fixed...
When a file is loaded, scan the file :
If it uses tabs, great. Do nothing. If it uses spaces, work out the indentation size, and convert all leading spaces into the appropriate number of tabs. Issue a warning if there are badly aligned indentations (e.g. a stray line, which starts on column 3, where everything else is a multiple of 4).
When a file is saved, and the original used spaces, replace tab characters with the appropriate number of spaces. The only down side I can see : lines that were incorrectly aligned by 1 column will now be aligned correctly ;-)
I call that a down side, because the "diff" will now include a line of code which wasn't deliberately changed.
I've not noticed an editor which does this, but then again, I haven't looked.
Other Considerations
Disk Usage/Download Speed
Really? Is that a big deal for you? Disk usage is irrelevant these days.
If you really care about the download speed of html/javascript, then exclude indentations from the output. Also, web servers and browsers negotiate compression, so large indentations have minimal overheads???
Fun fact: Back in the day, I was told to write HTML with capitalised tags, because the compression algorithm worked better with upper case letters. Not sure if that was actually true.
My website has a boolean setting which causes all of the html to switch from human readable to compressed. It took no effort on my part.
It is also common practice to compress javascript, so that not only is all unnecessary white-space eliminated, identifiers are squished to be short and meaningless. I don't do this, but I do exclude leading white-space.
There must be One Standard
Really?
If I open your code, I expect my editor to respect the indentation encoding of your file. If it doesn't that's a bug in my editor (or I haven't configured my editor correctly).
If this is the cause of contention, we shouldn't fight each other. We are programmers god damn it, we should fix our editors! Even if our editors are too monstrous to fix, we could write a macro which runs whenever a file is loaded, scans the document, and updates the indentation preference temporarily. This macros only needs to be written once per editor: sharing is caring.
Likewise, If I copy/paste code I expect my editor to convert the indentation appropriately
Is Indentation Size Really a Personal Preference?
Let's say we have a language which is deeply indented (where 10+ levels of indentation is common).
Is it really a personal preference for each developer to choose indentation size?
Suppose you choose 2 columns per indentation, and your editor has 100 columns. If there's 20 levels of indentation, that means you have 60 columns for the actual code, ignoring indentation.
Now suppose I choose an indentation of 4, and I also have 100 columns. I can't read your code without scrolling.
You are still imposing your preference on me.
IMHO, the choice of indentation size should be much more contentious than the way indentations are encoded.
There's nuances here though. The 2 column guy and the 4 column guy will get on fine if the 4 column guy has a wider editor (measure in columns).
Conclusion
In practice, I see very little reason for disagreement.
Set up your editor "correctly", and your keystrokes will be identical, regardless of how indentation is encoded.
Everyone I know uses 4 columns for C style languages and therefore the the "imposing my will" argument becomes moot.
For languages with extremely high levels of indentation, yes, there's now scope for disagreement.
PS. I've deliberately used the long winded phrase tab character, rather than just tab, because tab has two meanings. A key on the keyboard, and a character. I know a tab-character guy who assumed that space guys use the spacebar to indent. Ah, bless!
My Personal Preference
Does it really matter?
Let's just say I can copy/paste my code anywhere, without tinkering, and it remains sanely formatted ;-)
Can you?
2024 Update
I've written a text editor, which has a feature that I've not seen elsewhere.
Tab and Shift-Tab indent and unindent by your preferred number of columns. No surprise so far.
Moving the caret using the arrow keys or mouse never leaves it in an inappropriate position (e.g. if your indent width is 4 columns, then the caret will never be in column 2 when the line starts with white space).
So, does it use spaces or tabs? The answers is either. I can't tell the difference between tabs and spaces. They behave EXACTLY the same.
If I open the file in a different editor, I can tell the difference (or if I copy/paste it elsewhere).
I think this feature should be available in every text editor. It's great. There is a downside though : I get pissed off when I have to use a different editor without this feature ;-) I have no idea why every editor doesn't support this. It was easy to implement.
I realise this isn't the answer to the flame wars. It doesn't address the idea of personal preference for indentation width. Everybody has to agree on one value (possibly on a per-file basis). But it should give some comfort to tab-lovers forced to work on a space-ridden codebase. Space-lovers should like it too??? It doesn't have the anti-feature that most tab-lovers moan about when forced to use spaces (potential misalignment)