In theory, one could use tabs to indicate indentation of the block and use spaces to indicate a line continuation or to make things vertically aesthetic:

sub foo {
<tab>while (<FOO>) {
<tab><tab>chop;
<tab><tab>   /^ \s* (\w+) \s* = \s* " (.*) " $/x
<tab><tab>or /^ \s* (\w+) \s* = \s*   (.*)   $/x
<tab><tab>or die "Malformed line $. in FOO";
<tab>}
}
[download]

It is unambiguous from the tabs that the first // is at the same block level as its surrounding lines. Unambigous, at least, to a machine or to somebody with visible tabs and/or spaces.

That said, I don't do this, and I've never seen anybody that did. (But I use pico and I don't have many friends. (Draw your own conclusions there.)) And if not everybody follows the convention, then you can't rely on the system.

FWIW, I have had to work with code indented twice around the screen before the inking characters, and had I been using an editor that would shorten tabs, I'd have still ended up with one in ten lines having 160 leading spaces. While K&R and Linus probably overgeneralized with the three-indent rule, I've yet to see any code whose biggest flaw was the characters it used for spacing.

While indent and perltidy are marvelous tools, we also need "unindent" and "perluntidy". Each would take (1) the original source before you got stuck with it, (2) the tidied source, and (3) the tidied source plus your fixes, and spit out (4) the fixed source in the style of the original.

In my entire life, no matter how much people may disagree on how many spaces to use for each indent level, I have never heard anyone offer a compelling reason to use TABs to indent source code.

Smaller size? For example:

$ unexpand < bbbike | wc -c
 488645
$ expand < bbbike | wc -c
 605458

When you can buy a 500 GB hard drive, size is not a good reason to use tabs.

----
: () { :|:& };:

Note: All code is untested, unless otherwise stated

My iPAQ still has only 64MB RAM and 16MB Flash. And my mobile phone just only 4MB RAM.