Two space indentation seems to be the new craze. “Four space indentation? Are you mad, that’s nearly as bad as tabbing with eight?” is the meme of the moment. (Or, as established in Zoolander, “Two spaces? It’s so hot right now.”)
While two space indentation offers more horizontal space to work, four spaces continues to create an elegant sense of white-space and scope-based horizontal stepping that provides light and easy reading.
(I ignore the three space addicts in this discussion, while acknowledging they do exist. As Mike Ash puts it, “I think three spaces should be, ‘Do not approach. Retreat to a safe distance and call the police as soon as you’re clear.‘” Chris Lattner counters, “I think you under appreciate 3 space indent. It looks the best, and conclusively settles the tabs vs spaces debate.” coughtrollcough1)
Like my previous colon discussion, Apple answers seem to vary by group. Apple docs, including the Swift Programming Language, consistently use four spaces, enabling clean examples that breathe:
and the Standard Library group uses 2, following LLVM Coding Standards, which I find a bit claustrophobic. (Thanks, Greg!)
So I went off to google. First up, I found a 1983 ACM paper by Richard Miara, Ben Schneiderman, and some others called “Program Indentation and Comprehensibility“, which sought to test whether 2-4 spaces were more ideal than 0 or 6 spaces. Unsurprisingly, this premise was born out by their research.
They found that indentation level had a statistically significant effect on comprehension, and optimal indentation fell somewhere between 2 and 4 spaces. As the spacing increased beyond that (6 spaces or more), comprehension decreased.
It’s worth noting that all testing was done: (1) in the 1980’s (2) on 80-column-limit systems, and (3) with choices limited to 0, 2, 4, and 6 spaces. “The level of indentation we tested (0-6 spaces) gave strong results favoring 2 or 4 spaces.” The paper recommends that more indentation levels (0-8 spaces, or nine total levels) be studied in further depth. I’m sure someone got around to it before Starbucks and the MacBook Pro were invented.
In contrast, there’s the Jay Bonci codex (Perlmonks, 2002, “The One True Style of indentation“), a sociological introspection of indentation. Here’s a subset of the Bonci codification that maps spacing choices to internal coding intent.
- One space – Screw readability. I’m pissed they even make me separate my operators. Perl should be more like Latin.
- Two spaces – I have my head on straight AND I respect screen real estate.
- Three spaces – I have a little flair, or a nervous twitch. Or the second disguised as the first. Or you listen to waltz while you code.
- Four spaces – I read a few standards docs and now I think I’m all spiffy. Vannila (sic) Ice, I know you’re in there.
- Six spaces – I have agression (sic) issues, and my outlet is machine gunning the space bar
- Eight spaces – You end every line with a meniachal (sic) “DIE! HAHAHAHAH! DIE! YOUR FRIENDS CANNOT SAVE YOU NOW.”
- Tabs – I’m a lazy person. I know all of the vi commands by heart. Or you drank the 80’s soda.
In the real world, indentation seems to have settled on two, four, and sadly three space standards. So what’s your indentation style? And why?
1 My personal use of 3-space indentations have almost entirely been predicated on accidental deletion of a member of a 4-space unit, but they have happened.
38 Comments
I often wonder what the issue with 3 spaces is. Is it because it’s not an even number?
It feels weird
Everything feels weird until it doesn’t. 3 is my favorite.
The standard library uses 2 spaces because all parts of the Swift project use 2 spaces, because they follow the LLVM Coding Standards, which specifies 2 spaces. Every other Apple code I’ve ever seen outside of the Swift compiler uses 4.
I’m a 4 spacer myself, but not for any particular reason I can defend – that’s just what people around me were using when I started coding and what I got used to.
Thanks, noted in-text.
4 – because, text looks clearly and through split to blocks better for concentrating.
Definitely two spaces. One of my pet peeves is when lines of code are so long that they have to wrap around to multiple lines. Not always avoidable, especially with some of Apple’s APIs, but two spaces per indent helps minimize that behavior while still maintaining readability.
But it’s 2016. We have big screens now.
Not all of us use big screens all the time, nor do we want to use the full screen for just the code window. I code on my laptop and my iMac. I tend to keep my line length capped at 120 characters. That said, I still use four spaces over two as I can scan the indentation levels quicker.
I read code on a variety of screens, from a 30″ monitor to a 5.5″ phone. Bigger screens facilitate more, but that doesn’t always have to mean “wider editor”. For example, I like to use the screen real estate for vertical splits, so I can see two or more files at once. 80 characters as a width limit helps to facilitate that. I also disabled line-wrapping in my editor because it absolutely ruins all the readability that carefully formatting code provides.
Tabs, although usually configured as 4-space ones.
Spaces are nice for visual layout, but are a nightmare for editing when formatting changes. “Oh, you just removed a letter or word? Have fun editing the next twenty lines to make sure everything lines up with the new top-level line length.”
Yeah, it’s impossible to screw up if you search&replace tabs with spaces. The other way around, there’s always a few sections that are screwed up. That’s all you need to know.
I use tab. Because then I can use editor settings to change the tab be 1,2,3,4,5… spaces depending on what feels right. I’ve been at this for 30 years and style and requirements have changed and will change. Presbyopic eyes can’t quite deal with 2 so I use 4.
My solution is to just use tabs. Each developer on a project can then use whatever width they prefer (I prefer 4 space tabs myself). But apparently my “everyone wins” solution is just another dog in the fight.
I’m a strong believer in not modifying the IDE auto-formatting settings, which all seem to be 4 spaces.
As i get older i opt for 4 spaces over 2 for a simple reason: My eyes are not getting better and reading 2 spaces is actually harder even though i’m only a little short-sighted.
Why does line spacing never come up in these discussions? I find two spaces “breathes” plenty when the lines aren’t all crammed together. More: http://practicaltypography.com/line-spacing.html
3 spaces. It’s the perfect compromise between 2 and 4.
People who use tabs but change the value of a tab to something other than 8? Now those are the people who you “do not approach. Retreat to a safe distance and call the police”.
This precisely. As the post says: “optimal indentation fell somewhere between 2 and 4 spaces” which is … *does integer math* … 3. I just don’t see why 2 and 4 seem reasonable and 3 becomes “sadly”. Python has actually made me have to think about this; I went back and looked at my old c/SQL/perl/PASCAL/whatever code and I actually use a combination. But I most frequently use 3.
Using hard tabs allows people to choose their indentation preference, while sacrificing the inane practice of lining up function arguments. I find it the least rude choice for projects with >1 developer. The rest of the Obj-C/Swift world seems to disagree with me.
I agree. Tabs are the best for indentation because each tab represents a level of indentation and the spacial representation for said indentation level can be left up to each developer.
What utter nonsense. 5 spaces is, obviously, the only rational way to indent. 7 is acceptable too.
Not just rational; prime.
I am flexible. I am exceptionally appeased beyond all expectation when source is already indented. I have followed terrible programmers into maintaining projects, and do not hesitate to use all sorts of tools to fix things in order to make them clear. I personally don’t care whether the indentations are 2, 3, 4, 6, or 8 spaces, just as long as the previous developers did not slam each line along the left edge of the window. I’ll even use tabs, if tabs are the established standard and the spacing is assigned.
I think it depends what language you use. For ruby I use two space, I feel my code clean and clear. Four space seems being too much. For swift too. But when talking abou Objective-C, Java or C#, I use 4 spaces. These 3 last languages are more verbose and I feel they need more space between statements to be clear
I’m a 4denter.
Tabs, set to 7 spaces. Proportional font. Line wrapping.
And writing your code in Word, obviously.
I prefer 4 spaces. I still do coding on a mainframe and so am limited on screen space (80 columns). It looks better and clearly delineates that the following line is related to the preceding line..
I see the argument over what the “best” indentation level is to be the original bike shed discussion. It never leads to productive exchange of views, it’s simply used as a club by the “In” group to beat on the “Out” group. It’s the ultimate personal preference turned into a “culture fit cue.”
Using tabs for indentation and spaces for alignment is, in my view, the most accommodating solution. It allows those who choose to use 2 spaces to use 2 spaces. It allows those who have handicaps (such as dyslexia) to adjust the spacing to what works best for them. It even allows the minority that like 3 spaces to use 3 spaces. As a bonus, it uses less space on disk (although that is definitely a nicety, not a determining factor.)
The only argument against tabs I have heard that’s valid is that some people can’t seem to distinguish between indentation and alignment. That seems fixable through education to me.
Tab indents, and I do not use a monospace font, so “2 space indent” means nothing.
Mono space fonts are a hangover from the 1960s, and represent a horrible practise known as skeuomorphism.
The whole point of using tabs is that you can set the spacing in your editor rather than the document, so every one wins.
I prefer to use negative numbers
The only good answer is: whatever is comfortable for YOU, and have a tool that lets everyone choose, because everyone is different and has different reading preferences and reading (dis)abilities. Ah if only modern editors where able to detect (or be told) what the indentation used is, and then let the viewer choose how to display it (and transform back the result of the tab key). I’m pretty sure I have seen some editor do that some day. Then again you should not rely on specific tools when something already available everywhere solves it: tabs that you set the width of in the editor. Personally I set for stun, I mean 4. I find 2 unreadable. Then again, I also find a long list of arguments on a single line with soft wrap hard to read, and who knows what else.
Anyway, my point is: tab=4.
LOL, that Bonci excerpt is hilarious, as are several of the comments here. I’m a 2-spacer. I picked it up writing tutorials for RayWenderlich.com and it stuck with me.
The beauty of tabs (to indent, spaces to align) is that you decide what they are when you’re reading it. I hit a tab and call it four spaces. You flip a switch and see it as 2, 3, 4, or 99 for all I care.
[…] Swift Style: Are you a 4-denter? Never thought it’s might be very important, but I falled into styling problems because of Ray Wenderlich examples and books. They use 2 spaces everywhere, but I prefer four. For me it is still – personal feeling of the text on the screen, but Open Source world and sites like RayWenderlich change it to kind of “school” you prefer. […]
Thank you for this discussion!
I agree that neat code is essential for large projects. I figured that 3-space indentation works really well and together with 108 chars maximum line length (not 80) allows for neat and readable 1-liners.
With blocks of related code (functions, objects, conditions, etc), I find that white-space and comment plays a very important role in professional looking code; for example:
// func :: bark : emit barking
// ——————————————————————–
function bark(arg)
{
console.log(arg || ‘Woof!’);
}
// ——————————————————————–
// cond :: value : to bark or not
// ——————————————————————–
if (animal == ‘dog’)
{ bark(‘BaWow!’); }
// ——————————————————————–
So, in the example above, the line comment `// ` (including the space) have 3 characters and line up very well with indenting the actual code away from the direct margin.
The `{` being on its own line is on purpose also, utilizing white-space to designate that this is the start of a context, for in case a long line was used to define the start of this context, so it’s easy to find at one glance.
The condition’s context (execution block) is on 1 line because it is very short, hence not necessary for 3 lines, still it is on its own line.
I hope this is useful/acceptable.
ciao