Death to the Space Infidels!

Ah, spring. What a wonderful time of year. A time when young programmers' minds turn to thoughts of ... neverending last-man-standing filibuster arguments about code formatting.

This is a companion discussion topic for the original blog entry at:

@Chris Noe: It’s a total non-issue on the command line. That’s what god invented tr for.

A response:

Quoting from the article, … depending on the type of formatting, can also damage your ability to effectively compare revisions in source control, which is really scary. …

In answer to that problem, why isn’t there a syntax/semantics sensitive compare utility?

What I mean is, I would like a version compare utility that knew what was significant and what was insignificant. It would have classes of changes to be checked for that could be controlled independently.

The most restrictive level would flag every mismatch of whitespace, tabs, newlines, comment text, and everything above that. A somewhat more lenient level would ignore semantically meaningless differences in whitespace, tabs, newlines, etc (but not in strings, presumably), but would flag other changes.

The most lenient level would NOT flag anything but semantically meaningful differences.

For instance, and assuming all references were also changed consistently, renames inside a function of arguments and local variables would not be flagged as changes.

Also, renames of private functions would not be flagged as changes.

This would solve the problem of code reformatting and code cleanup making it difficult to compare revisions. With the current compare technology, a simple reformatting of the code can make the revision compare system flag practically every statement in the source file, making it difficult to find the real changes.

Does anything like this exist?

Theoretically, tabs have a semantic distinction that spaces don’t. But in the real world, neither is used in the semantic sense – they are used to present the code in a visually appealing and understandable way. Even in python, it’s about the semantic value of alignment, not the semantic value of a tabstop.

The only tool I can remember with TAB as a semantic value is Make, and that was an quite obviously horrible mistake.

And, again, in real practical experience, tabs are almost never consistent from person to person for large projects – even if they are using the same editor. Spaces are always consistent, and editors for over 25 years now have done the proper thing with spaces when you press the TAB key, so those who think the difference between 5 characters typed and one character typed is actually significant need to upgrade their editors. :slight_smile:

TABs are, frankly, a relic.

@Jeremy: didn’t try using Ctrl+F before posting, did you? :smiley:

I favour three spaces and work at a place that uses four, which isn’t so bad. I autoconvert tabs to spaces.

In my ideal world we’d all use stickytabs which aligns to logical boundaries defines by the syntax of the line above rather than to arbitrary column widths, but most editors don’t do this and if they did, I doubt it would be terribly consistent.

Tabs are easier to press and spaces guarantee consistency across all views without any configuration, so my call is for some number of spaces (certainly no more than 8, and preferably no more than 4). Also, I am the sort of person who tends to align assignments and declarations and so forth, since I find it is far easier to read down one column that way.

The one style I have a hard time with is KR style braces. I far, far prefer Allman style. I can see the point of a few others, but I’m used to Allman. I don’t agree with the argument that the new whitespace necessarily makes it clear because when I’m looking down the left hand side of the current code context, a sudden blank could mean an indent or it could mean somebody pressed enter twice to separate logical sequential code blocks, so I have to look over to the right to determine which it is, or else read the previous line to see if it’s a continued block statement. For similar reasons, I prefer putting the braces down even on one-line statements. KR just increases horizontal eye movement. The case where a block is so large that the vertical space matters on a modern monitor should be rare, kind of like the case where the open brace would get cut off horizontally in KR should be rare.

That guy Cyrus you mentioned has it exactly right: tabs for indentation, spaces for alignment. Then people can adjust the indent level to be whatever they want (I happen to like 3) and everything still aligns correctly. I wrote some indentation code for emacs to properly indent according to the tabs for indentation, spaces for alignment concept. Works great.

If I’m working on my own code only, I prefer tabs, because I hate it when editors make me hit backspace four times to clear out to the start of the line. It also makes changing the formatting much easier - want a 2-space tab instead of 4? Just click a setting.

But for anything that anyone else will ever see I use spaces, just because I have seen so many idiotic settings make code completely unreadable in many editors when using tabs.

It’s like giving your files lower case names without spaces and with an extension on a mac (mycat.jpg instead of Picture of my Cat) - on your own system, you don’t need to do that crap. But when you work with other people you have to go to what works with the lowest common denominator.

  1. The single largest source of bugs in the Python code at my last company came from the (accidental) use of tabs.
    … which leads to …

  2. I’ve never seen a tab-based codebase that did not have a mixture of tabs and spaces. This works great until the one day you need a tool that chokes on the mixture.

  3. In my experience, tabs tend to be preferred by programmers who spend most of their time in Microsoft Visual Studio style IDEs.

As others have said before, a space is a space and there is no ambiguity.

I can tell novices and just plain bad programmers by how they indent (or not) their code. I can tolerate most anything except code that isn’t indented correctly.

People that use spaces to indent are forcing their view of the code on others. If you use tabs I can switch the code from your view to my view just by editing the file.

Remember it’s called the Art of programming. Make your code look beautiful to everyone. And yes, surface beauty (how the code looks) counts.

This is a dumb argument.
Who cares!

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

Then call me a moron, because I can’t stand spaces.

(stupid rationalization)Besides, you save so much disk space by using a single tab character instead of four space characters. Ergo, tabs are better. QED.(/stupid rationalization)

Always use spaces. As has been pointed out, tabs are handled inconsistently, while spaces are always handled the same. It doesn’t cost extra time either, any real editor or IDE can be configured to output spaces in the place of a tab.

My current employer has relatively strict guidelines on code formatting, and I’m glad it does. In fact I still sometimes spend time reformatting other people’s code to make it more legible.

I find it difficult to believe so much effort is wasted on this crap.

I’ve never had any form of discussion with co-workers on whether to use scheme X vs Y. Either our workplace is amazingly like-minded (hah) or more likely we have much better things to do with our time.

Solution: Pick an editor or IDE which does this worrying for you. Or if you’re particularly insistant: has a preference to layout your code in the way you want.

Now go solve some other more pressing problem – like world peace. Or perhaps just making sure your code actually works (How’s your test coverage?)

I’m partial to tabs, myself, simply because they’re more flexible. Spaces are fine if it’s my own code, but I’d much rather use tabs and be able to set my own width if I’m on a team where someone likes it wider/narrower than myself.

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

sarcasmI’m glad to see your subtlety was not lost on this group…/sarcasm.

Atwood spends several hundreds of words on nothing, really:

  1. There is a religous war centered around formatting code.
  2. Pick a formatting standard that works for you and your team. If no team member is truly happy with all the elements of your standard, you probably have the right one.
  3. Set up a checkin hook to enforce/fix the formatting issues.
  4. Move on

I know I have commented on various topics on SO related to this. sigh. So many posts from jeff lately must mean that there is nothing to work on over at SO these days…

Problems at Stackoverflow code base or is it just from another situation?

I never cared much about spaces vs tabs. What I do care a lot is:

int main() {
return 0;


int main()
return 0;

Spaces vs. tabs is a minor skirmish in the formatting wars. This is the issue over which blood is truly spilt.

I work on a project where the convention is 3 spaces for indenting. I spent a few minutes googling up the necessary vim magic that makes vim understand this, and then I can type exactly as I’m used to, using tabs, as it were, yet get the 3-spaces format. even lt;lt; works correctly.

Only morons use tabs? Them’s fighting words.

Here’s a suitable arena: