Tabs versus Spaces in Source Code

[Duncan Booth]

Sorry but this is just wrong. Python works out the indentation level
for a source file dynamically: see
http://docs.python.org/ref/indentation.html. The particular algorithm
it uses is designed to accommodate people who mix tabs and spaces
(which is unfortunate, and should probably be changed). Nevertheless,
using tabs only, one tab does indeed map to exactly one indentation
level. One tabstop == one indent, on your editor and on mine.

Using spaces everywhere allows this, using tabs everywhere
allows this, mixing spaces and tabs is a bad thing.

Yes, if you use tabs only tabs map to exactly one indentation level, but
as soon as there is a mix it breaks horrible. The problem arises because
in most situations there is no visual distinction between tabs and
spaces so it isn't obvious when there is an accidental mix until things
break.

Fortunately Python is reasonably robust, and in most cases you will get
a syntax error instead of a silent change to the meaning of the code.

You do not need to know my display convention to run my code.

The Python interpreter does not know your display convention either: it
assumes that tabs expand to 8 character boundaries. So long as you have
pure tabs this doesn't matter, but if there is any mixing it means that
any editor set to expand tabs to a different width will no longer
display the indentation as the interpreter sees it.

The problem is that although you are a tab purist (as I am a space purist),
too many people out there are neither. If you set an editor to only insert
spaces then it is unlikely to accidentally insert tabs, but if the editor
is set up to do indentation with tabs then a naive user is still likely to
use the space bar occasionally and then wonders why Python is complaining
about an error when they can see (with their 4 space indents) that
everything is indented correctly.

 

[Sybren Stuvel]

Duncan Booth enlightened us with:

In particular a common convention is to have indentations at 4
spaces and tabs expanding to 8 spaces.

Aaaw that is SO ugly! Sure, it displays correctly on systems that have
tab stops every 8 spaces given a monospaced font, but that is about
all that is positive about that.

Sybren

 

[Sybren Stuvel]

Duncan Booth enlightened us with:

It is strange. You use many of the same words as me, but they don't make
any sense.

You forgot to add "to me" to the end of that sentence. Personally,
Achates' words made perfect sense to me.

The point is about separating the presentation of the source file
from the semantic content. When displaying the file you can choose
to expand tabs to any suitable positions. These may be evenly spaced
every n characters, or may vary across the page.
True.

However the important thing is that a tab does not map to a single
indentation level in Python: it can map to any number of indents,

True, but doesn't the same hold for spaces? An indent level can be
made from any number of spaces. You could use two spaces to indent a
class' contents, four for functions, and two again for loops.

and unless I know the convention you are using to display the tabs I
cannot know how many indents are equivalent to a tabstop.

That is only true if you mix spaces and tabs. If you use only tabs OR
only spaces to indent, everything is perfectly clear.

Precisely. Using spaces everywhere allows this

No it doesn't! I have tabstops every four characters, which is a
pleasant indent level for me. Other people have trouble reading the
code that way, and want two or eight character wide indents. When
using tabs, everybody can place the tabstops for themselves, and as
long as tabstop N is more to the left than tabstop N+1, everything is
fine. By using spaces, the writer of the code determines the size of
the indentation, not the viewer. Since code is generally read more
than it is written, the viewer is quite important.

Sybren

 

[Ant]

I think Duncan has hit the nail on the head here really. I totally
agree that conceptually using tabs for indentation is better than using
spaces. Pragmatically though, you can't tell in an editor where spaces
are used and where tabs are used.

Perhaps if editors colored the background of tab characters differently
from spaces this wouldn't be a problem, or if Python was more
restrictive and did not actually allow a mix of tabs and spaces for
indentation there would be no problem - the compiler could throw out an
exception for mixed characters. In reality, neither of these are likely
to be implemented any time soon!

The following quote sums things up nicely I think:

"In theory there is no difference between theory and practice, but in
practice there is."

(No idea where I got that from BTW - someone's tag-line probably)

 

[Iain King]

I think Duncan has hit the nail on the head here really. I totally
agree that conceptually using tabs for indentation is better than using
spaces. Pragmatically though, you can't tell in an editor where spaces
are used and where tabs are used.

Um, I don't follow this. If you can't tell the editor where
tabs/spaces are used, who does?

Perhaps if editors colored the background of tab characters differently
from spaces this wouldn't be a problem,

Some editors do.

or if Python was more
restrictive and did not actually allow a mix of tabs and spaces for
indentation there would be no problem - the compiler could throw out an
exception for mixed characters.

python -tt

In reality, neither of these are likely
to be implemented any time soon!

um

Iain

 

[Andy Sy]

This has been discussed repeatedly, and the answer is "If you only
work alone, never use anyone else's code and no one ever uses your
codes, then do as you please. Otherwise use tab-is-4-spaces."

When you do Agile Programming with people using emacs, vim, nedit,
xedit, wordpad, eclipse, and who knows what else, the 4-spaces rule is
necessary for survival.

The reason is simple: People get confused, and accidentally get the
wrong tab indents when they move among editors or among settings on
the same editor. In most languages this is an irritation, requiring
some cleanup. In Python it is a disaster requiring re-inventing the
coded algorithms.

1. Tabs as 8 spaces just take up way too much horizontal
space, so you can't use 8-space tabs...

2. BUT... you can't use any other value (not even 4)... !!

WHY??

Because if you do, you will screw up display using /something
as basic as cat, less, more (and many other unix utilities
where the historical assumption that tabs are 8 spaces
is hardcoded)!


DOES ANYONE NEED ANY REASON MORE COMPLICATED THAN THE ABOVE TO
JUST *NOT* USE TABS??


Yet ANOTHER proof that tabs are evil:

3. If tabs weren't around, we wouldn't have all these
time-wasting threads on tabs vs. spaces, or on how many
spaces a tab should represent.


Tabs were an unnecessary Rube Goldberg invention misguidedly
carried over from the typewriter era. They are the appendix
of text editors. Just because they're there doesn't necessarily
mean they serve any (even remotely) useful purpose.

 

[Andy Sy]

Please... just stop this senseless defense of
a Rube-Goldberg feature.

There will NEVER be a universal agreement on
whether tabs should be 2, 3, 4 or 8 spaces in
width, and this causes endless tweaking of editor
settings (a *humongous* waste of time) to handle
source code made by other programmers with different
settings.

And I, for the life of me, have never remembered
getting any source code to display properly by
fiddling with my text editor's (the very popular
SciTE) tab settings.

4, 8, 3, 2, it doesn't matter. *Nothing* has ever
made someone's tab-infested source code display
completely cleanly. Nearly a third of my coding
time seems to have been spent (read:wasted) trying
to reformat some unenlightened tab user's source code
to read comprehensibly.



1. Tabs as 8 spaces just take up too much horizontal area

2. But you can't use any other value because if you do,
you will screw up display using cat/less/more !!

DOES ANYONE NEED ANY REASON MORE COMPLICATED THAN THE ABOVE TO
JUST *NOT* USE TABS??!???!??!!!??

Don't be evil - always configure your editor to
convert tabs to true spaces.

 

[achates]

python -tt

Indeed. I reckon the consensus here (to the extent that there is any!)
is that it would be better if this was Python's default behaviour.

The argument (not advanced by Iain but by others in this thread) that:
novices will mix tabs and spaces => we should all use spaces only
is clearly false by symmetry.

An alternative solution to this issue would be to write an editor
plugin which converted between space-indented and tab-indented Python
source files on opening *and back again* on writing or closing. Then we
would have:

Case 1: you send me a space-indented file.
My editor opens the file, finds that it is space-indented,
calculates the indentation level of each line and converts it to the
corresponding number of tabs, and then writes that to a temporary file
which it then displays for editing. On writing, it converts indentation
back to spaces and writes to the original file.

Case 2: I send you a tab-indented file.
As Case 1 with s/tab/space/; s/My/Your/

Case 3: You send me a file with mixed tab/space indentation
Everything borks, as it should.

It's horrible but at least it would insulate me from the greater
hideousness of having to hit the spacebar like a madman at the start of
every line of code. I can even see how to get it to work in vi at
least.

Just trying to be constructive!

Not that it's relevant, but I've never actually encountered anyone who
mixed tabs and spaces.. I've lived a sheltered life I guess.

 

[achates]

Don't be evil - always configure your editor to
convert tabs to true spaces.

Yet another space-indenter demonstrates that problem actually lies with
people who think that tab == some spaces.

And I, for the life of me, have never remembered
getting any source code to display properly by
fiddling with my text editor's (the very popular
SciTE) tab settings.

Sorry to hear that. You should try using an editor that's easier for
you.

By the way, complaining about a thread's existence is pretty dumb. If
you don't like it, don't post to it. Or are you unable to operate your
news reader either?

 

[Ant]

Um, I don't follow this. If you can't tell the editor where
tabs/spaces are used, who does?

Re-read my post. Note the key word 'in'.

Some editors do.

Some isn't nearly good enough to solve the problem.

python -tt

Not the default behaviour, and so not good enough for tabs to be a good
indent character.

um

OK. Widely implemented and default behaviour.

Your points are fine if you are working by yourself (hell you could use
Perl and it wouldn't matter ;-) ), but in for example an open source
project where work is distributed over developers working in vastly
different environments, tabs currently aren't a workable option.

 

[Ant]

Not that it's relevant, but I've never actually encountered anyone who

mixed tabs and spaces.. I've lived a sheltered life I guess.

It's not individuals using a mixture, but when working in a development
team of some kind. Consider person A who writes a file using spaces for
indent. Person B then edits that file, adding a few lines of code,
indenting using tabs. It could soon get messy!

 

[Nick Craig-Wood]

I think Duncan has hit the nail on the head here really. I totally
agree that conceptually using tabs for indentation is better than using
spaces.

As a programmer tabs appeal to our sense of neatness in python code.
One tab for each level of indent - very nice.

Back in the last century when I wrote nothing but assembler in a
series of primitive text editors I would have agreed with you. Tabs
rule! label TAB opcode TAB arguments TAB ; comment.

Pragmatically though, you can't tell in an editor where spaces
are used and where tabs are used.

Now-a-days when I am writing Python, I just use emacs which indents
perfectly. I press tab and emacs inserts the correct of indentation.
Most of the time I don't have to press tab at all - emacs knows how
much indentation I need.

I don't actually care whether emacs inserts spaces or tabs (spaces
actually), it works, looks nice and follows PEP 8. It's a lot less
keystrokes than writing assember too ;-)

If you are writing python using "cat" or "ed" then tabs might matter
again, but for any modern editor with a python mode it really doesn't
matter!

The following quote sums things up nicely I think:

"In theory there is no difference between theory and practice, but in
practice there is."

;-)

 

[Duncan Booth]

It's horrible but at least it would insulate me from the greater
hideousness of having to hit the spacebar like a madman at the start of
every line of code. I can even see how to get it to work in vi at
least.

Hitting the spacebar like a madman? If you have a sensible editor then at
the start of a line you press tab once for each additional level of
indentation and backspace once for each fewer level and neither if the
indentation is guessed correctly by the editor.

in another post you suggested to someone else:

 

[David Isaac]

Yet another space-indenter demonstrates that problem actually lies with
people who think that tab == some spaces.

Exactly.

Cheers,
Alan Isaac

 

[achates]

Hitting the spacebar like a madman? If you have a sensible editor then at

the start of a line you press tab once

True! but normally if I'm editing someone else's code then I'm only
making small changes and so can't be bothered to temporarily cripple my
editor. If I'm merging my code with someone else's space-indented code
then piping through sed 's/TAB/SPACES' does the trick.

 

[Sybren Stuvel]

achates enlightened us with:

True! but normally if I'm editing someone else's code then I'm only
making small changes and so can't be bothered to temporarily cripple my
editor. If I'm merging my code with someone else's space-indented code
then piping through sed 's/TAB/SPACES' does the trick.

I just type 'retab' in my editor, and everything is fine. I use VIM,
which is great for tab/space management.

Sybren

 

[Andy Sy]

If tabs are easily misunderstood, then they are a MISfeature
and they need to be removed.

From the Zen of Python:

"Explicit is better than implicit..."
"In the face of ambiguity, refuse the temptation to guess..."
"Special cases aren't special enough to break the rules..."

 

[Andy Sy]

Yet another space-indenter demonstrates that problem actually lies with
people who think that tab == some spaces.

Wrong. I am completely aware that an editor configured to
convert tabs to true spaces will not always replace a tab
into the same number of space characters.

If you understood what I meant you'd realize that it meant: "Use the
tab key if you have to (4,8,3,2... whatever...), but /always/ have your
editor convert them to true spaces, so they can display properly -
*without need for tweaks* - on any display medium and on anyone's
program.

The fact that a tab character doesn't necessarily equal a constant
spaces is what makes things EVEN MORE CONFUSING. Cheez... some
people just love complexity for its own sake...



What earthly benefit is there anyway to mixing tabs and spaces??!?

Now... if you say you SHOULDN'T mix tabs and spaces (indeed this is
generally regarded as a BAD idea esp. in Python code), then WHAT THE
HECK do you need to use tab characters in the source code for anyway
(besides saving a measly few bytes) ??!?


Tab characters are EVIL *AND* STUPID.

Sorry to hear that. You should try using an editor that's easier for
you.

I am *most certainly* NOT giving SciTE up... I've spent years and years
looking for the perfect editor, and I've found it with SciTE. Scite and
all its cool features are NOT the problem. One single thing is:

Tab characters in source code popping up like so many unsightly zits.

 

[Jorge Godoy]

True! but normally if I'm editing someone else's code then I'm only
making small changes and so can't be bothered to temporarily cripple my
editor. If I'm merging my code with someone else's space-indented code
then piping through sed 's/TAB/SPACES' does the trick.

Emacs guess what's used in the file and allows me to use tabs all the time,
doing the correct thing... Personally, I like using spaces, but I don't
have problems with files using tabs...

--
Jorge Godoy <[email protected]>

"Quidquid latine dictum sit, altum sonatur."
- Qualquer coisa dita em latim soa profundo.
- Anything said in Latin sounds smart.

 

[Peter Decker]

If tabs are easily misunderstood, then they are a MISfeature
and they need to be removed.

I don't seem to understand your point in acting as a dictator.
Therefore, you are a MISfeature and need to be removed.