Death to the Space Infidels!

Follow up post. Several modern editors will you to highlight/block off one or more lines of code such that when you press tab or shift-tab the editor will indent/un-indent that code with spaces not tabs unless of course you are still using tabs (see previous post).

No - quite definately this is about trivial changes, locations of spaces, tabs as well as Variable and Function names. This is nothing about cleaning code, but entirely about reformatting. And that is what has me scratching my head.

If you think variable or function names are trivial, as in unimportant, well then I could hardly disagree more. They are the essence of readable code. The well named variable will usually eliminate the need for a comment, and the well named function will make code understandable in a way no amount of commenting will allow. And readable code is the heart of maintaining a large source base.

If your team lead is removing contractions and adding specificity to your variables and function names, then he is showing that he has been burnt by these things in the past and is trying to save both of you long term pain. You would be wise to learn from this.

When the team that reports to me switched from a waterfall development method to extreme programming, we decided we would actively try the shared code ownership practice. One of the recommendations of that practice was consistent formatting. We didn’t have long battles, but we had dissent in the team that could not be resolved.

We were coding in Java, so we decided we would adopt Sun’s Java coding standard. We were then delighted to find the open source version of jalopy which was able to format the code to enforce that coding standard.

We made that switch in 2003, and the team adapted very comfortably to having the code formatting fixed each time they compiled the code. The formatting step was an integral part of the build process, and was supported by a nightly automated task which checked out all the Java code, formatted, and checked in anything that was changed by the formatting.

That was over 5 years ago, and that code base is still being developed, still being actively formatted to a single consistent style, and I believe the developers on the project are glad for the consistent formatting. Comparing file versions is easy, and no time needs to be given to making formatting consistent. It will be made consistent by the tool.

I believe the program astyle can do the same thing for other languages, as can indent for C.

The details of the standard seem to have been less valuable to us than the fact that there was a standard and it was automatically enforced.

I’ve always been a fan of both.

Personally I use tabs for html and markup languages, while I use spaces for other languages.

Tabs have a strategic advantage in html. If you don’t have the plus of using gzip compression a tab is equal to that of 4 spaces. Meaning you can indent in less characters. I recall several years ago optimizing an awful table based page by simply converting spaces to tabs. Saved several Kb, which over a dial up connection made a difference.

For things that are compiled, server side, or file size doesn’t matter, I prefer spaces (4 to be exact) since that seems the easiest on the eyes and the most consistent across platforms.

The tab argument is tempting, but it doesn’t actually abstract spaces away. Because of tab stops. Tab stops, or spaces multiple of 8 functionality mean that everyone will see tabs differently.

Spaces, if you aren’t brain dead, will at least look sane on all editors. Tabs can make code look ridiculous, especially if one person uses tab stops or multiples of 8 and another interprets tabs as spaces.

Unless you refuse to use a fixed-width font, in which case there’s no help for you and you’ve probably given up looking at code in any sensible fashion anyway.

I don’t agree with the don’t use Tab argument. Every code editor I’ve used in my career, from multi-edit to SQL Query Analyser has the ability to customise font, colours and Tabs. In fact, if you are in an environment where Tabs can’t be adjusted - perhaps you should consider changing IDE.

I think one thing missing from this debate is the fact that different developers frequently develop with different visual settings.

I find standard black on white letters a bit hard to see and after some experimenting I’ve found Comic Sans MS in 12 font to be used. Another developer here prefers a black screen with light coloured fonts. Yet others go defaults all the way.

But spaces look different under different fonts, but tabs don’t (at least not on our environments. But I agree with Mark Waite above - automatic re-formatting makes sense.

The third style makes most sense, and allows you to adjust code indentation for clarity.
It is increasingly important to use the most flexible method of indentation when dealing with multiple authors since it’s not reasonable to assume that everyone else wants to read your code using the same indentation length.

The discussion should never be tabs vs. spaces, it’s about correctly representing the indentation you want to achieve.

Just because your editor sucks, doesn’t mean you should make others suffer while reading your code. (write once, read many times, remember?)

Why anyone prefers spaces over tabs is beyond me, it’s like saying we only need a single datatype when we are representing fundamentally different things.

I don’t think there is anything wrong with tabs for indenting flow control and such. If there is a problem it’s far easier to convert tabs to spaces than spaces to tabs. Either way no matter what you do there will be a point where the kludge is as inescapable as it is laughable.

However there is one thing I must point out. Do not always rely on an IDE to apply white spaces. At least, don’t rely on it entirely and blindly.

Of course as mentioned if you can use a tool with some parsing ability (so it knows what is a literal string, comment and so on) to clean up your code. Again as mentioned, use a constant width font.

If the option is presented to you, always turn show white space characters on. I’ve seen some coding horrors where the use of spaces and tabs is completely inconsistent (even on the same line OMG). Worse still due to the way tabs work and auto align I’ve seen spaces in a column (at least a column where tabs are concerned) that are totally useless. A particular problem I’ve also noticed with IDE’s in particular but can generally occur in any case where white space is actually plain white is whitespace at the end of lines.

It makes my blood boil.

@Jonathan: That’s awesome. Elastic tabstops. It addresses both problems, and ends up promoting a standard that most people use tabs / spaces to do manually anyway. With a bit of tweaking, it could even reformat code, and handle anyone’s preferences quite simply.

I like.

I wonder how hard it would be to hack into Xcode and/or TextMate.

what’s amazing about this discussion is how every criticism of tabs seems to be based on the idea that it’s a bad thing to let the reader view code according to their personal preferences. That sure seems like a positive thing to me!

Everyone keeps saying things that amount to But if someone else chooses to view it with different preferences than mine, they won’t see it with my preferences!. Yes, that’s correct. Isn’t that good? If they want to view things with your preferences, they can use your preferences.

50 pages of comments in a few days over spaces vs tabs…

The point I’m trying to make is that tabs alone do not allow the source code to be read according to your own preferences.
The elastic-tab convention is currently the only real solution to this problem.
If everyone in a project adheres to it, then everyone can read the source code in the way they see fit, and therefore avoid useless commits or other nonsense.

Tabs should only be used as the special indent character they are supposed to be and spaces for representing any kind of manual deviation from ordinary indentation.

Emacs supports the third option:

this is so cool. i think you should mix the tabs and spaces together.

Ahahaha, what a wonderful post. It just never ends.

What kind of insanity has emacs done!?

Vim has it too, now:

Yes, it never ends.

Now I throw the question to all the no-tabbers. What does it matter if one editor interprets a tab as 4 or 8 or 2 or what ever width of characters. IMHO, that is what is so good about tabs. If a coder whats to see the code with 2 character wide intends, he is free to do so. If another wants to see it as 8, just set it like that. No big deal. One tab per one level of indentation. I don’t understand what is so difficult about this. I can’t stand some of these editors that insert spaces instead of tabs. If they’d also backspace the same about of spaces that would be fine. But no. I hit tab and then have to backspace 4 spaces. WTF? I’m lazy. :wink: Oh and tab stops should not exist in a real text editor. OK? WTF is that? Tab stops? Something from a damned word processor. Yawn…

I actually prefer to use neither. Indentation tends to push the code too far off to the side. If you don’t indent anything, all of the code will be neatly lined up on the left margin.

I wrote a small script a few years back that strips any whitespace from the beginning of each line. It works great and keeps code looking nice.

nick said it correctly: “TABS work great in that most popular editors have preference settings related to how many spaces to use when representing a TAB, this way if one developer likes to look at it with 2 spaces and another with 4… the TAB is displayed to the developers liking.”

The key here, which people who still use Notepad don’t understand, is that a good editor displays a tab as a number of spaces, and that number is configurable (in good editors, of which Komodo is one). The source code file remains unchanged, and everybody can be happy. Separation of data and presentation has gotten into this area as well. People simply need to stop using Notepad as a software development editor (it’s designed to write notes, not programs).