Tabs versus Spaces in Source Code

Edward Elliott nobody at 127.0.0.1
Mon May 15 20:07:24 CEST 2006


Brian Quinlan wrote:

> The problem with tabs is that people use tabs for alignment e.g.
> 
> def foo():
>    ->query = """SELECT *
>    ->  ->  ->   FROM sometable
>    ->  ->  ->   WHERE condition"""

Sure it's a problem.  When programmers do bad things, what is your response? 
Slap his nose and say 'Bad, don't do that'?  Or take away his toys so he
can't do that?  Therein lies your answer to tabs or spaces.  Both are
rational.

> Of course, a very disciplined group of people could be trained to
> never use tabs except to align with the current block level but, in
> practice, that doesn't work. Therefore tabs are bad.

Consistency is always hard for people and easy for machines.  If you make it
a machine task instead of a people task, it can easily work in practice,
just like Python easily enforces no mixing of tabs and spaces with the -tt
flag.  Get editors that use different (background) colors for tabs and
spaces so you can easily pick them out even when the above alignment
problem isn't noticeable.  Use editors that automatically pick the right
character when indenting: tabs to the level of indentation of the current
block, then spaces afterward for line continuations.  Run the code through
parsers that detect and flag inconsistencies on check-in.

If such tools are lacking, use substitutes in the meantime.  Don't allow any
code to be checked in where a line departs more than one tab indentation
level from its neighbors.  It's not perfect, but it eliminates the worst
offenses.  Good enough often is.

Not saying you should do this, just pointing out how tabs are viable.

-- 
Edward Elliott
UC Berkeley School of Law (Boalt Hall)
complangpython at eddeye dot net



More information about the Python-list mailing list