Why I love having tabs in source code.

Many people indent with spaces. But this is a bad idea in general. If tabs were used for indentation, and spaces were used for generic formatting, we wouldn't have this problem. Decent editors that cooperate with tabs properly are at least VIM and KWrite.

Reasons why the arguments at http://www.new.ox.ac.uk/~adam/computing/why_no_tabs.html don't work are as follows:

• It's less portable, since different editors/pagers render a hard tab as varying numbers of spaces, and most editors can have this number altered on a per-user basis too. If you use spaces instead of tabs, you're never relying on a particular editor or pager to have tab width set correctly. Even if you're prepared to configure every editor/pager/platform combination you use, aren't you going to be making life difficult for others who want to read or modify your code?
  It's more portable in fact. I don't know anyone who indents with spaces actually does press the space key 8 times, they would in most cases set their text editor to assume that the tab key is 8 spaces. It doesn't matter how deep your tabs are, the reader of the text file can just set their depth to whatever they want, and not have to reformat the file. Reformatting the file (with indent, for example) makes diffs completely impossible since the whole file will be different. Tabs solve the problem, whether they use 4-space indents, 8-space indents, or others, since it doesn't change the file, just how it appears.
• It makes context/unified diffs far harder to read. This is a pretty important point for many coders these days. Even if you're not collaborating with others on your code, how certain are you that no-one else will ever want to look at it or modify it and maybe even send you patches?
  This is a complete untruth, in fact, indenting with tabs makes diffs far easier to use, as I've stated above.
• It makes re-indenting sections more difficult; if for example you try to shift a block two columns right, it might have no effect on lines starting with tabs. Decent editors do automatic indentation anyway of course, but there are often circumstances (especially in Perl, where even GNU emacs can't always parse the syntax correctly) when they don't do the right thing. And again, how certain are you no-one else will want to re-indent blocks of your code at a later point?
  Automatically re-indenting your files with sed or perl is in fact easier when using tabs because each level of indentation is always exactly one character, there's no need to count, no need to guess if the tab width is 8 spaces or 4 spaces or otherwise. Any editor that doesn't cope with tabs isn't an editor, but a bug (emacs comes to mind).
• The `tabs are good because then you can choose your own tab width' argument doesn't work because:
  • Tabs aren't just used at the beginning of lines. There might be a left-aligned, multi-line comment to the right of a block of code. Say someone is on an 80x25 terminal and decides they want to view the code with 2 or 3 space indentation, because all the 8 space tabs are forcing loads of the code to wrap onto the next line (or off the screen), decreasing readability. They type less -x2 foo.pl, and bam, suddenly that rectangular comment block is no longer left-aligned -- it's a mess. Tabs are meant to indent, that's exactly what they do, that's only what they do. They're not meant to format text, to align it in columns, to put your comments into a regular block. Spaces do that.
  • There can be problems even if tabs only occur at the beginning of lines. For example, say that some code was written in emacs with tab width set to 8 spaces, but the indentation style is Kernighan & Ritchie, which has basic indentation 5 spaces wide. If emacs is set to use tabs, lines indented one level will start with 5 spaces, and lines indented two levels will start with one tab followed by two spaces (8 + 2 == 10). If someone else tries to view this code setting their editor/pager tab width to 4, first level lines will be indented 5 columns, second level lines 6 columns, third level lines 11 columns ... oops!
    This isn't a concern if you modify the K&R style into tabs style, where every tab is exactly X spaces. Where the column will be X*level. K&R Style is obsolete in the first place.

In fact, the advantage of hard-tabs is demonstrated by the kde cvs repository. Most applications are indented with spaces, most of those are inconsistently tabbed. Of the few tabbed modules (aRts, Noatun), the code is exactly 100% consistent.

Indenting the following way is best. Tab will be an underscore, space will be a dot:

_____if.(true)....//This should be replaced
_____{............//with a proper boolean
__________func();
_____}

At any indentation level, all will align.

SomeClass::SomeClass()
_____.:.InheritingClass(false, false
_____...................5, 10, true,
_____...................bleh, blah)
{
// ....
};

// vim: ts=4 noet