Tabs versus Spaces in Source Code ('semantic' vs. arbitrary indentation)

Dave Hansen iddw at
Thu May 18 02:12:07 CEST 2006

On 17 May 2006 16:13:54 -0700 in comp.lang.python, "achates"
<aylwyn at> wrote:

>Carl J. Van Arsdall wrote:
>> The converse can also be said, "it's difficult to make sure everyone
>> uses spaces and not tabs".
>> I think we've just about beat this discussion to death... nice work
>> everyone!
>Yeah - we've got to the repeating ourselves stage.
>But that's the problem with this issue: it's really hard to get the
>space-indenters to actually think about it and to address what is being
>said. Every time it comes up, there's always a few people trying to

Look in the mirror.  There is non so blind...

>explain why tabs give are a good idea, facing a whole raft of others

The problem is that TABs are a _bad_ idea.

>spouting stuff like:
>    'mixing spaces and tabs is bad so use spaces only'

Mixing TABs and spaces is bad because it means using TABs.  ;-)

>    'tabs are x spaces and I like to use y spaces'

I've not seen that argument.  One of us needs to read closer.

Although I have seen the converse used to defend TABs: x spaces is x
spaces, and I like y spaces,  

>    'tabs are bad end of story'

Works for me!  ;-)

>and these non-arguments are repeated over and over within the same
>thread. At times it's like talking to a child - and not a bright one at

These "non-arguments" are your own straw men.  Either that, or you
need to work on reading comprehension.

>Does it matter? Perhaps not if we can use tools which enable us to
>bridge the divide, like indent auto-detection in emacs and vim. I'm
>prepared to do that in cases where I have to work with an existing
>group of coders uasing spaces.

It matters because not every programmer is willing to put in the time
effort required to learn how to use a sophisticated editor like emacs
or vim well.  Or at all.   

It matters because in industry you get programmers with a wide range
of skills, and you can't fire everyone who can't tell when there are
spaces in front of a tab character.  Often these people have unique
and hard-to-find domain knowledge.

>But unfortunately the situation is worse than that: tab indentation
>needs to be actively defended. Most of the coding 'style guides' you'll

No, it needs to be stamped out.  ;-)

>find (including Python's) advocate spaces only. There are plenty of


>people who would like tabs removed from the language as an acceptable
>indentation method - look at the responses to Guido's April Fools blog
>entry last year.

I would love to see the TAB character treated as a syntax error.  I
have no illusions that's going to happen, though.

FWIW, I would be equally (well, almost, anyway) happy if Python said
that the _only_ place a TAB character could appear was at the
beginning of a line, and that the number of TAB characters _always_
indicated the indentation level (e.g., spaces do _not_ change
indentation level, and all the lines in a multi-line statement had to
be at the same indentation level).  This would eliminate most of my
objections to TABs.  I have no illusions this will happen either.

>Unlikely perhaps. I hope so. It's a cruel irony that Python's creator
>didn't appreciate the benefits that tab indentation would bring to his
>own language - the only major language in which indentation levels
>actually have semantic significance.

The problem with TAB characters is that they look just like the
equivalent number of space characters.  This is, of course, their
major feature as well.  The problem, especially with Python, is that
mistakes in the placement of TAB characters within a source file can
silently change the _meaning_ of the code.

TAB proponents seem to list one overriding advantage of using TAB
characters for indentation: "I can use my preferred indent level, and
everyone else can use theirs."  I find this argument _very_ weak. I've
seen misuse of TABs break code.  I've never seen an enforced
indentation level break a programmer.


Change is inevitable, progress is not.

More information about the Python-list mailing list