Death to the Space Infidels!

This feels so wrong to say, but tabs or spaces depends on the project, the language, and the coding environment. All the languages and IDEs I use are tab friendly, so I’m with the folks that think using spaces interferes with other people’s preferences in viewing the code.

But on the topic at hand (and not just the flagrant comment baiting) it really doesn’t matter what the conventions are as long as they’re followed by the team. Automated code style translators are an extra layer of hassle in a project. Do they work? Are they introducing bugs? Who cares. Just agree on a style and get on with your day. With a clear standard to follow nobody should be bitching about having their code cleaned up.

For all of my programming I personally use tabs. For projects at a corporation where I work we also use tabs.

Spaces just complicate the matter, my text editor is smart enough to recognise 4 spaces as a single tab if I have set 4 spaces as my tab size (generally set to 8, that way I know a code block is too big if the lines are longer than the default width of my editor.

Using spaces just seems absolutely wrong, yes there is less issues about code formatting being displayed on someone elses computer and or IDE, but at the same time it is forcing them to accept the fact that you want 4 spaces for indents, what if they prefer 8? Tabs can be given any markup. spaces already have one pre-assigned that can’t be changed without drastically altering the way the rest of the code looks and lives.

In my team we have agreed to use TABS with indent size equal to 4. I’m really like double spaces, but we decided to use default IDE settings for C++ code. We have to use 26 FULL HD displays since then and everyone seems to be happy.
There is no difference between using TABS and Spaces until every developer use the same indent size.

There are some files (YAML for example) that require space-indenting. As far as I know there are none that require tab-indenting.

Space-indenting is absolute. Tab-indenting is relative to the editor.

For these two reasons, which can be combined to one - consistency - I prefer spaces.

BTW a good editor can convert tabs to spaces for those addicted to the tab key.

As said multiple times above: the tab character is a welcome bit of indirection.

IMHO, I like the third style (mixed spaces and tabs), although I try to avoid instances where that becomes necessary.

The ONLY space where indentation width matters is when trying to align multiple columns together such as in a convoluted if (…) test with a dozen conditions and subconditions. There, spaces make a lot of sense, because they make that essentially fixed-width. Although, I’d hasten to add that if you don’t use a monospaced font (ah, that other religious war …) tabs make more sense here again.

IMHO, though, tabs could still be used every time. Yes, convoluted if statements end up looking ugly when you go from one tab size to another, but in keeping with the last post and numerous others, bad code should look like bad code. I’d rather see the semantic cohesion which had been applied with whitespace instead affixed in the code; break up the multi-line if statements into multiple tests, and change the signature of your library method from requiring 27 parameters to taking a couple data objects.

Primary arguments for tabs:

  1. Fewer characters to type on every line / indentation. Most editors auto-indent for us, and some properly auto-unindent, but if you care about most of the arguments for using spaces, this is just as viable.

  2. Impossible for alignment to be lost. I have a few developers on my team who use 4 spaces instead of tabs, and nary a week goes by when I don’t find a block of code that got indented by 3 tabs or 5 tabs instead of 4. Granted, if you are using the IDE for indentation (use the tab/shift-tab indent/unindent instead of space/backspace multiple times) you don’t hit this issue. But, I find it incredibly rare to find space-loving developers who do this.

  3. Reformatting for print or other viewport sizes is easy and built in to any decent text editor. I routinely compress/expand my indentation when getting a better look at code or printing it out. On my laptop’s screen horizontal real estate is far too precious to be wasted on indentation; on my dual-screen desktop nice wide indentation settings keep code scannable.

57 comments and nobody has mentioned … drum roll …

StyleCop.

– J

Of course, the real issue here is that the visual representation is inextricably tied to the actual code. If editors operated on ASTs, we wouldn’t be having this discussion…

Yes, you can’t edit it with emacs anymore. I’ll cry for you. Heck, I’ll even throw in an XML version for free - go edit that.

Actually, now I’m seriously wondering if you can format code using nothing but XHTML and CSS… :wink:

I have my own preferred style (2-space indents, opening braces on same line) but when working on a file with a majority different format I always simply adapt my code changes to that format. Not a big deal and it maintains consistency at least per-file.

If a team specifies spaces then they must also specify and enforce the standard number of spaces or nothing will line up after multiple edits from other devs or it quickly becomes the mess you sought to avoid.

If a team specifies tab then anyone can, in almost every modern editor, specify their own ‘tab size’ and ‘indent size’ and it will not only appear consistant but in the preferred format of the viewer.

While you believe that anyone who thinks using tabs is a moron, IMHO I believe anyone who prefers spaces is a noob.

Meh, and to think I once respected you as a programmer Jeff. By using spaces you violate two important ideas:

  1. Tabs are designed to indent. That is their function.

  2. Using spaces instead of tabs is the same as embedding CSS in HTML. You’re forcing markup into places it shouldn’t be. If you like 2 spaces, then set your IDE to show tabs as 2 spaces. Don’t force your preferred indentation on others who might prefer 3 or 4 spaces.

Tabs vs Spaces has been a non-argument for the last 10 years. We’re not programming over teletype anymore.

Anyone who says tabs are sufficient has not understood the problem as shown in the third option example above. Had that example been done with tabs only, the string s would not correctly align for people who used a different set of tab stops. Think about it.

No matter which side you’re on, clearly sometimes spaces are needed. But I agree with Jeff, there’s never a need for a tab.

Anyone who says I hate pressing space multiple times does not understand that nobody does that–we all press tab and the editor inserts spaces.

Yes, every IDE lets you set your tab stop to whatever you want. But do you always use your IDE? I read more code than I write: I use three different tools that do diffs for me: the p4 diff, the Code Reviewer diff, and Beyond Compare. I bring up code in notepad++ sometimes, I email code sometimes, I format code in a wiki sometimes, and I print code sometimes. Even if it’s possible, I don’t want to set my custom tab stops in all of these tools. Spaces are consistent.

@jake

absoulutely…rite…
i think those who use spaces are morons…
So it shud be said like this by jeff

That said, only a moron would use spaces to format their code.

I don’t get it. Modern IDEs (at least mine does) enable you to specify the correct formating of spaces, braces and other mission critical formating rules. So each developer can in fact see a different view of the same code. Provided you use tabs and spaces for their intended purposes…
Why is this still an issue?

I’m a big fan of editors that convert tabs to spaces. Also, absurd though it sounds, I was quite impressed with the idea of combining tabs and spaces to properly align the code independently of indentation, that was a neat idea.

I guess the hardest part about all of this is not so much choosing a style as it is keeping that style consistent among your teammates. I actually have less issues with the tabs vs spaces issue, that I can fix. I find the most disagreement over where the opening and closing brackets should go. I always do this*:

if (condition)
{
statements;
}

but a lot of people like to do this*:

if (condition) {
statements;
}

which I find a lot harder to read. This is where I’ve found that auto-formatters are great for reading other people’s code. I could care less what the variables and things are named, but an auto-formatter at least gets it somewhat into a structural form that I would use myself, which makes it a lot easier to read. I would recommend one to anyone who does a lot of code review, because once you have it tailored to your own style it really is a godsend.

*there should be a tab or 4 spaces in front of the statements but I’m not sure they’re going to keep when I post this.

Use a combination of two tabs and two spaces for every indentation and everyone is happy.

@herman

then why isn’t everyone happy?

Tabs are better because they don’t take as much space. Plus there is the possibility that you commit only tabs, and then in IDE you can adjust how many spaces long you want a tab to be. That way if I like 2 long tabs, then fine, I use that. If you like 3 long tabs, then fine, you use that. But in version control it is just a tab.

Anyways I think there should be a one coding standard, and if it is not as good as I want, I want to change it, of course. If there is some lead developer who can say what kind the standard is, then I say my objections or change job, but that’s it. Having a fight over it isn’t worth it.

You don’t know the true joy of format wars until you use a graphical programming language…

One of absolute worst, worst methods of teamicide for software
developers is to engage in these kinds of passive-aggressive
formatting wars.

It’s hard to say from this little anecdote what’s going on here, but in my experience, this sort of thing is almost always about more than just spaces/tabs/conventions. Unfortunately, to the less-experienced coder (and original author), changes to his code often just look like useless cleaning. But I’d bet that senior guy called it refactoring.

Yes, I’m one of those senior people who sometimes refactors someone else’s code, so call me evil. But once the code goes into the project for which I’m responsible, it’s officialy our code. And as that guy, let me say that if a piece of code works reliably and exposes a sane API, I’m certainly not going to waste my time wading through it to pick nits with internal variable names or spacing.

No, the only times I’ve come in and cleaned code, it has always started by pulling on a thread: a bug, an API problem, a namespace collision, something. Once inside, sometimes the only way comprehend the issue is to engage in a little refactoring to expose the code’s structure: making functions orthogonal, giving variables sane names, and yes, even whitespacing the code according to standards. All this lets the senior guy understand the code, isolate the issues, and fix them. And when he checks in the code, it’s just a little better than he found it, like a Boy Scout on a trail.

Unfortunately, sometimes the less-experienced guy doesn’t see the merit, and that can cause painful ego-collisions. The good folks eventually figure out how to disassociate themselves from the code and learn from the changes. The not-so-good folks are often bent on protecting a code castle. (Perhaps having their code understandable and accessible by other team members works against their job security.)

In fact, anybody having email exchanges with Mr. Atwood is probably not one of those job security folks. Maybe the senior guy in this story just has a bad case of OCD and really does go around randomly whitewashing perfectly good code for pleasure. But I wouldn’t assert that code cleaning is always face stabbing. If the code is genuinely better for it, isn’t that a good thing?

Back in the old days, a common freshman FORTRAN programming error was to use the TAB character. The code looked fine on the screen, but the compiler had all kinds of fits. My pals and I were confounded as to why retyping the offending line exactly as we had the first time–or by having someone else retype it–allowed the compiler to accept the code. It wasn’t until a few years later, in the compiler design course, I could look back and understand what was going on.