Tabs versus Spaces in Source Code
Xah Lee, 2006-05-13
In coding a computer program, there's often the choices of tabs or
spaces for code indentation. There is a large amount of confusion about
which is better. It has become what's known as “religious war” —
a heated fight over trivia. In this essay, i like to explain what is
the situation behind it, and which is proper.
Simply put, tabs is proper, and spaces are improper. Why? This may seem
ridiculously simple given the de facto ball of confusion: the semantics
of tabs is what indenting is about, while, using spaces to align code
is a hack.
Now, tech geekers may object this simple conclusion because they itch
to drivel about different editors and so on. The alleged problem
created by tabs as seen by the industry coders are caused by two
things: (1) tech geeker's sloppiness and lack of critical thinking
which lead them to not understanding the semantic purposes of tab and
space characters. (2) Due to the first reason, they have created and
propagated a massive none-understanding and mis-use, to the degree that
many tools (e.g. vi) does not deal with tabs well and using spaces to
align code has become widely practiced, so that in the end spaces seem
to be actually better by popularity and seeming simplicity.
In short, this is a phenomenon of misunderstanding begetting a snowball
of misunderstanding, such that it created a cultural milieu to embrace
this malpractice and kick what is true or proper. Situations like this
happens a lot in unix. For one non-unix example, is the file name's
suffix known as “extension”, where the code of file's type became
part of the file name. (e.g. “.txt”, “.html”, “.jpg”).
Another well-known example is HTML practices in the industry, where
badly designed tags from corporation's competitive greed, and stupid
coding and misunderstanding by coders and their tools are so
wide-spread such that they force the correct way to the side by the
eventual standardization caused by sheer quantity of inproper but set
practice.
Now, tech geekers may still object, that using tabs requires the
editors to set their positions, and plain files don't carry that
information. This is a good question, and the solution is to advance
the sciences such that your source code in some way embed such
information. This would be progress. However, this is never thought of
because the “unix philosophies” already conditioned people to hack
and be shallow. In this case, many will simply use the character
intended to separate words for the purpose of indentation or alignment,
and spread the practice with militant drivels.
Now, given the already messed up situation of the tabs vs spaces by the
unixers and unix brain-washing of the coders in the industry... Which
should we use today? I do not have a good proposition, other than just
use whichever that works for you but put more critical thinking into
things to prevent mishaps like this.
Tabs vs Spaces can be thought of as parameters vs hard-coded values, or
HTML vs ascii format, or XML/CSS vs HTML 4, or structural vs visual, or
semantic vs format. In these, it is always easy to convert from the
former to the latter, but near impossible from the latter to the
former. And, that is because the former encodes information that is
lost in the latter. If we look at the issue of tabs vs spaces, indeed,
it is easy to convert tabs to spaces in a source code, but more
difficult to convert from spaces to tabs. Because, tabs as indentation
actually contains the semantic information about indentation. With
spaces, this critical information is lost in space.
This issue is intimately related to another issue in source code:
soft-wrapped lines versus physical, hard-wrapped lines by EOL (end of
line character). This issue has far more consequences than tabs vs
spaces, and the unixer's unthinking has made far-reaching damages in
the computing industry. Due to unix's EOL ways of thinking, it has
created languages based on EOL (just about ALL languages except the
Lisp family and Mathematica) and tools based on EOL (cvs, diff, grep,
and basically every tool in unix), thoughts based on EOL (software
value estimation by counting EOL, hard-coded email quoting system by
“>” prefix, and silent line-truncations in many unix tools), such
that any progress or development towards a “algorithmic code unit”
concept or language syntaxes are suppressed. I have not written a full
account on this issue, but i've touched it in this essay: “The Harm
of hard-wrapping Lines”, at http://xahlee.org/UnixResource_dir/writ/hard-wrap.html
----
This post is archived at: http://xahlee.org/UnixResource_dir/w...vs_spaces.html
Xah xa*@xahlee.org
∑ http://xahlee.org/ 135  7318 
Actually, spaces are better for indenting code. The exact amount of
space taken up by one space character will always (or at least tend to
be) the same, while every combination of keyboard driver, operating
system, text editor, content/file format, and character encoding all
change precisely what the tab key does.
There's no use in typing "tab" for indentation when my text editor will
simply convert it to three spaces, or worse, autoindent and mix tabs
with spaces so that I have no idea how many actual whitespace characters
of what kinds are really taking up all that whitespace. I admit it
doesn't usually matter, but then you go back to try and make your code
prettier and find yourself asking "WTF?"
Undoubtedly adding the second spark to the holy war,
Eli
--
The science of economics is the cleverest proof of free will yet
constructed.
Xah Lee wrote: Tabs versus Spaces in Source Code
Xah Lee, 2006-05-13
In coding a computer program, there's often the choices of tabs or
spaces for code indentation. There is a large amount of confusion about
which is better. It has become what's known as “religious war” —
a heated fight over trivia. In this essay, i like to explain what is
the situation behind it, and which is proper.
Simply put, tabs is proper, and spaces are improper. Why? This may seem
ridiculously simple given the de facto ball of confusion: the semantics
of tabs is what indenting is about, while, using spaces to align code
is a hack.
i agree, tabs is proper and i always use the tab key to indent... it puts in 4
spaces.
Eli Gottlieb wrote: Actually, spaces are better for indenting code. The exact amount of
space taken up by one space character will always (or at least tend to
be) the same, while every combination of keyboard driver, operating
system, text editor, content/file format, and character encoding all
change precisely what the tab key does.
What you see as tabs' weakness is their strength. They encode '1 level of
indentation', not a fixed width. Of course tabs are rendered differently
by different editors -- that's the point. If you like indentation to be 2
or 3 or 7 chars wide, you can view your preference without forcing it on
the rest of the world. It's a logical rather than a fixed encoding.
There's no use in typing "tab" for indentation when my text editor will
simply convert it to three spaces, or worse, autoindent and mix tabs
with spaces so that I have no idea how many actual whitespace characters
of what kinds are really taking up all that whitespace. I admit it
doesn't usually matter, but then you go back to try and make your code
prettier and find yourself asking "WTF?"
Sounds like the problem is your editor, not tabs. But I wouldn't rule out
PEBCAK either. ;)
Undoubtedly adding the second spark to the holy war,
Undoubtedly. Let's keep it civil, shall we? And please limit the
cross-posting to a minimum. (directed at the group, not you personally
Eli).
--
Edward Elliott
UC Berkeley School of Law (Boalt Hall)
complangpython at eddeye dot net
Personally, I don't think it matters whether you use tabs or spaces for
code indentation. As long as you are consistent and do not mix the two.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Spaces work better. Hitting the TAB key in my Emacs will auto-indent
the current line. Only spaces will be used for fill. The worst thing
you can do is mix the two regardless of how you feel about tab vs
space.
The next step in evil is to give tab actual significance like in
make.
Xah Lee is getting better at trolling. He might fill up Google's
storage.
-- http://www.david-steuber.com/
1998 Subaru Impreza Outback Sport
2006 Honda 599 Hornet (CB600F) x 2 Crash & Slider
The lithobraker. Zero distance stops at any speed.
If I work on your project, I follow the coding and style standards you
specify.
Likewise if you work on my project you follow the established standards.
Fortunately for you, I am fairly liberal on such matters.
I like to see 4 spaces for indentation. If you use tabs, that's what I
will see, and you're very likely to have your code reformatted by the
automated build process, when the standard copyright header is pasted
and missing javadoc tags are generated as warnings.
I like the open brace to start on the line of the control keyword. I
can deal with the open brace being on the next line, at the same level
of indentation as the control keyword. I don't quite understand the
motivation behind the GNU style, where the brace itself is treated as a
half-indent, but I can live with it on *your* project.
Any whitespace or other style that isn't happy to be reformatted
automatically is an error anyway.
I'd be very laissez-faire about it except for the fact that code
repositories are much easier to manage if everything is formatted before
it goes in, or as a compromise, as a step at release tags.
Xah Lee wrote: Tabs versus Spaces in Source Code
Xah Lee, 2006-05-13
In coding a computer program, there's often the choices of tabs or
spaces for code indentation. There is a large amount of confusion about
which is better. It has become what's known as “religious war” —
a heated fight over trivia. In this essay, i like to explain what is
the situation behind it, and which is proper.
Thanks Xah. I value your posts. Keep posting. And since your posts
usually cover broad areas of CS, keep crossposting. Don't go anywhere
Xah :-)
Simply put, tabs is proper, and spaces are improper. Why? This may seem
ridiculously simple given the de facto ball of confusion: the semantics
of tabs is what indenting is about, while, using spaces to align code
is a hack.
I wouldn't say that spaces are a hack, but tabs are superior.
Now, tech geekers may object this simple conclusion because they itch
to drivel about different editors and so on. The alleged problem
created by tabs as seen by the industry coders are caused by two
things: (1) tech geeker's sloppiness and lack of critical thinking
which lead them to not understanding the semantic purposes of tab and
space characters. (2) Due to the first reason, they have created and
propagated a massive none-understanding and mis-use, to the degree that
many tools (e.g. vi) does not deal with tabs well and using spaces to
align code has become widely practiced, so that in the end spaces seem
to be actually better by popularity and seeming simplicity.
Don't forget the laziness of programmers like me who don't put the
tabbing information in the source file. Vim deals with tabs well IMO,
but I almost never used to put the right auto-commands in the file to
get it set up right for other users.
In short, this is a phenomenon of misunderstanding begetting a snowball
of misunderstanding, such that it created a cultural milieu to embrace
this malpractice and kick what is true or proper. Situations like this
happens a lot in unix. For one non-unix example, is the file name's
suffix known as “extension”, where the code of file's type became
part of the file name. (e.g. “.txt”, “.html”, “.jpg”).
Another well-known example is HTML practices in the industry, where
badly designed tags from corporation's competitive greed, and stupid
coding and misunderstanding by coders and their tools are so
wide-spread such that they force the correct way to the side by the
eventual standardization caused by sheer quantity of inproper but set
practice.
Now, tech geekers may still object, that using tabs requires the
editors to set their positions, and plain files don't carry that
information. This is a good question, and the solution is to advance
the sciences such that your source code in some way embed such
information.
Vim does this. We just have to use it.
This would be progress. However, this is never thought of
because the “unix philosophies” already conditioned people to hack
and be shallow. In this case, many will simply use the character
intended to separate words for the purpose of indentation or alignment,
and spread the practice with militant drivels.
Now, given the already messed up situation of the tabs vs spaces by the
unixers and unix brain-washing of the coders in the industry... Which
should we use today? I do not have a good proposition, other than just
use whichever that works for you but put more critical thinking into
things to prevent mishaps like this.
Tabs vs Spaces can be thought of as parameters vs hard-coded values, or
HTML vs ascii format, or XML/CSS vs HTML 4, or structural vs visual, or
semantic vs format. In these, it is always easy to convert from the
former to the latter, but near impossible from the latter to the
former. And, that is because the former encodes information that is
lost in the latter.
Nope. Conversion is relatively easy. I've written programs to do this
myself, and everyone and his brother has also done this. Virtually every
programmer's editor that I've ever used can do this, and a great, great
many independent programs convert tabs to spaces. It's like saying,
"it's near impossible to write a calculator program." :-)
I bet that someone has a Perl one-liner to do it.
On any Debian system, try a "man expand" and see what you find. Also,
emacs and vim do it. Perl has a Text::Tabs module. TCL's
::textutil::(un)?tabify routines do it. The birds do it, and the bees do
it. Oh wait, that's something else :-)
If we look at the issue of tabs vs spaces, indeed,
it is easy to convert tabs to spaces in a source code, but more
difficult to convert from spaces to tabs.
Nope again. It's easy, you just keep track of the virtual character
position as you decide whether to write a space or a tab. Computers do
the "counting" thing fairly well.
Because, tabs as indentation
actually contains the semantic information about indentation. With
spaces, this critical information is lost in space.
This issue is intimately related to another issue in source code:
soft-wrapped lines versus physical, hard-wrapped lines by EOL (end of
line character). This issue has far more consequences than tabs vs
spaces, and the unixer's unthinking has made far-reaching damages in
the computing industry. Due to unix's EOL ways of thinking, it has
created languages based on EOL (just about ALL languages except the
Lisp family and Mathematica) and tools based on EOL (cvs, diff, grep,
and basically every tool in unix), thoughts based on EOL (software
value estimation by counting EOL, hard-coded email quoting system by
“>” prefix, and silent line-truncations in many unix tools), such
that any progress or development towards a “algorithmic code unit”
concept or language syntaxes are suppressed. I have not written a full
account on this issue, but i've touched it in this essay: “The Harm
of hard-wrapping Lines”, at
http://xahlee.org/UnixResource_dir/writ/hard-wrap.html
----
This post is archived at:
http://xahlee.org/UnixResource_dir/w...vs_spaces.html
Xah
xa*@xahlee.org
∑ http://xahlee.org/
I've never thought of tabs-vs-spaces as a religious war. Anyway, the
authority of the programming environment will determine which one is
used. Have a good week Xah.
Edward Elliott <no****@127.0.0.1> writes: Eli Gottlieb wrote:
Actually, spaces are better for indenting code. The exact amount of
space taken up by one space character will always (or at least tend to
be) the same, while every combination of keyboard driver, operating
system, text editor, content/file format, and character encoding all
change precisely what the tab key does.
What you see as tabs' weakness is their strength. They encode '1 level of
indentation', not a fixed width. Of course tabs are rendered differently
by different editors -- that's the point. If you like indentation to be 2
or 3 or 7 chars wide, you can view your preference without forcing it on
the rest of the world. It's a logical rather than a fixed encoding.
[snip]
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.
--
Harry George
PLM Engineering Architecture
On 5/15/06, Chris Klaiber <ck******@gmail.com> wrote: The problem comes when the author prefers a smaller tab width than what my
editor is set to. Sure, I could change it for that file, but what if I'm
reading a whole directory? Sure, I could change the default setting in my
editor, but what if I'm browsing multiple projects in the same day? Sure,I
could find a way to set the tab width based on the directory I'm currently
in, but by now I'm annoyed and simply replacing tabs with spaces is a far
simpler solution that requires zero configuration on my part.
Funny, I was going to say that the problem is when the author prefers
a font with a differntly-sized space. Some of us got rid of editing in
fixed-width fonts when we left Fortran.
--
# p.d.
Harry George wrote: 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.
The answer is "Do what works best for your project". Smart people can agree
on and use whatever convention they want without trouble. The key is
consistency.
Otherwise use tab-is-4-spaces."
Tab is not 4 spaces. Tab is 1 level of indentation. The confusion that
tabs equals some fixed width, or can/should be set to some fixed width, is
the entire problem hampering their use. It implies that conversion between
tabs and spaces is straightforward when it is not. They are not comparable
entities.
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.
IOW reward programmers for being sloppy and using poor tools. Anyone who
programs in wordpad/xedit has far bigger problems than worrying about tabs
vs spaces (as do projects who let people program in wordpad/xedit).
Editors which are designed for programming handle tabs and spaces cleanly.
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.
Sounds like PEBCAK to me. :) If everyone uses tabs for indent, then it
doesn't matter if Joe's vim showed them as 3 spaces while Mary's emacs
showed them at 6. You can't get the 'wrong tab indents' when everything is
a tab indent. Mixing tabs and spaces is where you get problems.
In most languages this is an irritation, requiring
some cleanup. In Python it is a disaster requiring re-inventing the
coded algorithms.
Use the -tt flag to the Python interpreter and you'll catch inconsistencies
immediately. Voila, no disaster. Again, you're not complaining about
using tabs, you're complaining about mixing tabs and spaces. I completely
agree with you that the latter is way too much hassle to even attempt.
All I'm saying is that using tabs on their own is perfectly viable and a bit
cleaner. I'm not trying to force that preference on anyone else, just get
everyone to recognize that one is just as rational and salubrious as the
other.
--
Edward Elliott
UC Berkeley School of Law (Boalt Hall)
complangpython at eddeye dot net
Edward Elliott wrote: Tab is not 4 spaces. Tab is 1 level of indentation. The confusion that
tabs equals some fixed width, or can/should be set to some fixed width, is
the entire problem hampering their use. It implies that conversion between
tabs and spaces is straightforward when it is not. They are not comparable
entities.
The problem with tabs is that people use tabs for alignment e.g.
def foo():
->query = """SELECT *
-> -> -> FROM sometable
-> -> -> WHERE condition"""
Now I change my editor to use 8-space tabs and the code is all messed
up. 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.
Cheers,
Brian
On 5/15/06, Brian Quinlan <br***@sweetapp.com> wrote: The problem with tabs is that people use tabs for alignment e.g.
def foo():
->query = """SELECT *
-> -> -> FROM sometable
-> -> -> WHERE condition"""
Now I change my editor to use 8-space tabs and the code is all messed
up. 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.
And those of us who hate cutesy alignment like that think that people
who do it are therefore bad.
Spaces look like crap, too, when using proportional fonts.
--
# p.d.
Peter Decker wrote: Funny, I was going to say that the problem is when the author prefers
a font with a differntly-sized space. Some of us got rid of editing in
fixed-width fonts when we left Fortran.
Don't know what all of the hub-bub here is regarding tab/space
indentation. My punched cards break down such matters as in quite fine
fashion :-/
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
On 5/15/06, Edward Elliott <no****@127.0.0.1> wrote: 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.
I've recently adopted the Dabo convention of using two indent levels
to indicate continued lines, which helps distinguish such lines from
the indented blocks below them. But other than that case, one tab it
is!
--
# p.d.
Harry George wrote: 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.
People certainly do get confused. I'm always amazed that so many
people, even amongst those who manage to make a living out of writing
software, are unable to grasp the concept of a tab. But then a lot of
code is badly written, so maybe it figures.
A tab is not equivalent to a number of spaces. It is a character
signifying an indent, just like the newline character signifies the end
of a line. If your editor automatically converts tabs to spaces (i.e.
you are unable to create source files containing tabs) then either it's
broken or you have misconfigured it. Either way you probably shouldn't
be using it to write code.
achates wrote: A tab is not equivalent to a number of spaces. It is a character
signifying an indent, just like the newline character signifies the end
of a line. If your editor automatically converts tabs to spaces (i.e.
you are unable to create source files containing tabs) then either it's
broken or you have misconfigured it. Either way you probably shouldn't
be using it to write code.
That is true so far as it goes, but equally if your editor inserts a tab
character when you press the tab key it is as broken as though it inserted
a backspace character when you press the backspace key. In both of these
cases you have an operation (move to next tabstop, move back one space) and
an ascii control character which is intended to reflect that operation when
rendering the file to an output device.
An editor should be capable of letting you create or modify files
containing control characters without gratuitously corrupting them, but the
keys should perform the expected operations not insert the characters.
Duncan Booth enlightened us with: That is true so far as it goes, but equally if your editor inserts a
tab character when you press the tab key it is as broken as though
it inserted a backspace character when you press the backspace key.
In both of these cases you have an operation (move to next tabstop,
move back one space) and an ascii control character which is
intended to reflect that operation when rendering the file to an
output device.
That all depends on the setting of your editor. After all, a TAB
character could be the proper control character for the operation
'move to the next tabstop'.
An editor should be capable of letting you create or modify files
containing control characters without gratuitously corrupting them,
but the keys should perform the expected operations
I agree with that.
not insert the characters.
But not with that, since it is contradicting. "Inserting the
characters" could very well be the same as "performing the expected
operations".
Sybren
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa
Oh God, I agree with Xah Lee. Someone take me out behind the chemical
sheds...
Iain
Xah Lee wrote: Tabs versus Spaces in Source Code
Xah Lee, 2006-05-13
In coding a computer program, there's often the choices of tabs or
spaces for code indentation. There is a large amount of confusion about
which is better. It has become what's known as “religious war” —
a heated fight over trivia. In this essay, i like to explain what is
the situation behind it, and which is proper.
Simply put, tabs is proper, and spaces are improper. Why? This may seem
ridiculously simple given the de facto ball of confusion: the semantics
of tabs is what indenting is about, while, using spaces to align code
is a hack.
Now, tech geekers may object this simple conclusion because they itch
to drivel about different editors and so on. The alleged problem
created by tabs as seen by the industry coders are caused by two
things: (1) tech geeker's sloppiness and lack of critical thinking
which lead them to not understanding the semantic purposes of tab and
space characters. (2) Due to the first reason, they have created and
propagated a massive none-understanding and mis-use, to the degree that
many tools (e.g. vi) does not deal with tabs well and using spaces to
align code has become widely practiced, so that in the end spaces seem
to be actually better by popularity and seeming simplicity.
In short, this is a phenomenon of misunderstanding begetting a snowball
of misunderstanding, such that it created a cultural milieu to embrace
this malpractice and kick what is true or proper. Situations like this
happens a lot in unix. For one non-unix example, is the file name's
suffix known as “extension”, where the code of file's type became
part of the file name. (e.g. “.txt”, “.html”, “.jpg”).
Another well-known example is HTML practices in the industry, where
badly designed tags from corporation's competitive greed, and stupid
coding and misunderstanding by coders and their tools are so
wide-spread such that they force the correct way to the side by the
eventual standardization caused by sheer quantity of inproper but set
practice.
Now, tech geekers may still object, that using tabs requires the
editors to set their positions, and plain files don't carry that
information. This is a good question, and the solution is to advance
the sciences such that your source code in some way embed such
information. This would be progress. However, this is never thought of
because the “unix philosophies” already conditioned people to hack
and be shallow. In this case, many will simply use the character
intended to separate words for the purpose of indentation or alignment,
and spread the practice with militant drivels.
Now, given the already messed up situation of the tabs vs spaces by the
unixers and unix brain-washing of the coders in the industry... Which
should we use today? I do not have a good proposition, other than just
use whichever that works for you but put more critical thinking into
things to prevent mishaps like this.
Tabs vs Spaces can be thought of as parameters vs hard-coded values, or
HTML vs ascii format, or XML/CSS vs HTML 4, or structural vs visual, or
semantic vs format. In these, it is always easy to convert from the
former to the latter, but near impossible from the latter to the
former. And, that is because the former encodes information that is
lost in the latter. If we look at the issue of tabs vs spaces, indeed,
it is easy to convert tabs to spaces in a source code, but more
difficult to convert from spaces to tabs. Because, tabs as indentation
actually contains the semantic information about indentation. With
spaces, this critical information is lost in space.
This issue is intimately related to another issue in source code:
soft-wrapped lines versus physical, hard-wrapped lines by EOL (end of
line character). This issue has far more consequences than tabs vs
spaces, and the unixer's unthinking has made far-reaching damages in
the computing industry. Due to unix's EOL ways of thinking, it has
created languages based on EOL (just about ALL languages except the
Lisp family and Mathematica) and tools based on EOL (cvs, diff, grep,
and basically every tool in unix), thoughts based on EOL (software
value estimation by counting EOL, hard-coded email quoting system by
“>” prefix, and silent line-truncations in many unix tools), such
that any progress or development towards a “algorithmic code unit”
concept or language syntaxes are suppressed. I have not written a full
account on this issue, but i've touched it in this essay: “The Harm
of hard-wrapping Lines”, at
http://xahlee.org/UnixResource_dir/writ/hard-wrap.html
----
This post is archived at:
http://xahlee.org/UnixResource_dir/w...vs_spaces.html
Xah
xa*@xahlee.org
∑ http://xahlee.org/
Sybren Stuvel wrote: An editor should be capable of letting you create or modify files
containing control characters without gratuitously corrupting them,
but the keys should perform the expected operations
I agree with that.
not insert the characters.
But not with that, since it is contradicting. "Inserting the
characters" could very well be the same as "performing the expected
operations".
It could be, and for some keys (q, w, e, r, t, y, etc. spring to mind) that
is quite a reasonable implementation. For others 'tab', 'backspace',
'enter', 'delete', etc. it is less reasonable, but it is a quality of
implementation issue. If I had an editor which entered a control character
for each of these I would simply move to a better editor.
Some keys will of course do both (e.g. space bar in some editors does
completion and inserts a space), but I prefer editors which keep things
simple. The tab key is particularly prone to excessively complicated
actions, for example the editor I use has the following (not simple at
all, and in fact not even an accurate description of what it does) binding
for the tab key:
indent-previous command
Indent based on the previous line.
This command makes the current line start at the same column as the
previous non-blank line. Specifically, if you invoke this command
with point in or adjacent to a line's indentation, indent-previous
replaces that indentation with the indentation of the previous
non-blank line. If point's indentation exceeds that of the previous
non-blank line, or if you invoke this command with point outside of
the line's indentation, this command simply inserts a tab character.
If a region is highlighted, Epsilon indents all lines in the region by
one tab stop. With a numeric prefix argument, Epsilon indents by that
amount.
(and it is even more complex when you are editing something like Python
where it takes continuation lines into account working out the
indentation).
The problem is that behaviour like this is useful, and mostly even
intuitive, but it's a long way from the definition of a tab or even
the little metal clips you used to stick on the back of a manual
typewriter.
Duncan Booth enlightened us with: It could be, and for some keys (q, w, e, r, t, y, etc. spring to
mind) that is quite a reasonable implementation. For others 'tab',
'backspace', 'enter', 'delete', etc. it is less reasonable, but it
is a quality of implementation issue. If I had an editor which
entered a control character for each of these I would simply move to
a better editor.
Well, my editor *does* enter a control character when I press Enter,
namely \n. It also enters a \t when I press TAB. That does not mean my
editor is flawed.
The problem is that behaviour like this is useful, and mostly even
intuitive, but it's a long way from the definition of a tab or even
the little metal clips you used to stick on the back of a manual
typewriter.
I understand what you are saying, but saying "an editor that insert a
control character when pressing a key is flawed" is most incorrect.
Sybren
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa
Xah Lee wrote: Tabs versus Spaces in Source Code
Xah Lee, 2006-05-13
In coding a computer program, there's often the choices of tabs or
spaces for code indentation. There is a large amount of confusion about
which is better. It has become what's known as “religious war” —
a heated fight over trivia. In this essay, i like to explain what is
the situation behind it, and which is proper.
Simply put, tabs is proper, and spaces are improper.
[...]
I fullheartedly disagree :)
So, no "essay" on this is necessary to read :->
Ciao,
Oliver
> Simply put, tabs is proper, and spaces are improper. Why? This may seem
ridiculously simple given the de facto ball of confusion: the semantics
of tabs is what indenting is about, while, using spaces to align code
is a hack.
The reality of programming practice trumps original intent of tab
characters. The tab character and space character are pliable in that
if their use changes their semantics change.
... and the solution is to advance
the sciences such that your source code in some way
embed such information.
If/when time comes where such info is embeded perhaps then tabs will be
OK.
---------------------------------------------------------------
I use spaces because of the many sources I've opened I have many times
sighed on opening tabed ones and never done so opening spaced ones.
I don't get mad, but sighing is a clear indicator of negativity.
Anyway, the more code I write and read the less indentation matters to
me. My brain can now parse akward source correctly far bettter than it
did a few years ago.
All the best,
Opalinski op****@gmail.com http://www.geocities.com/opalpaweb/
"op****@gmail.com opalinski from opalpaweb" <op****@gmail.com> writes: Simply put, tabs is proper, and spaces are improper.
Why? This may seem
ridiculously simple given the de facto ball of confusion: the semantics
of tabs is what indenting is about, while, using spaces to align code
is a hack.
The reality of programming practice trumps original intent of tab
characters. The tab character and space character are pliable in that
if their use changes their semantics change.
... and the solution is to advance
the sciences such that your source code in some way
embed such information.
If/when time comes where such info is embeded perhaps then tabs will be
OK.
---------------------------------------------------------------
I use spaces because of the many sources I've opened I have many times
sighed on opening tabed ones and never done so opening spaced ones.
I don't get mad, but sighing is a clear indicator of negativity.
Anyway, the more code I write and read the less indentation matters to
me. My brain can now parse akward source correctly far bettter than it
did a few years ago.
And anyways, C-x h C-M-\ comes automatically after C-x C-f source RET
Just add this to your ~/.emacs :
(add-hook 'find-file-hook
(lambda () (indent-region (point-min) (point-max)) (pop-mark)))
--
__Pascal Bourguignon__ http://www.informatimago.com/
IMPORTANT NOTICE TO PURCHASERS: The entire physical universe,
including this product, may one day collapse back into an
infinitesimally small space. Should another universe subsequently
re-emerge, the existence of this product in that universe cannot be
guaranteed.
Iain King wrote: Oh God, I agree with Xah Lee. Someone take me out behind the chemical
sheds...
Xah Lee wrote:
<more worthless nonsense>
Please don't feed the troll!
And for the record, spaces are 100% portable, tabs are not. That ends
the argument for me.
Worse than either tabs or spaces however is Sun's mixture of the two.
--
Dale King op****@gmail.com opalinski from opalpaweb wrote: Simply put, tabs is proper, and spaces are improper.
Why? This may seem
ridiculously simple given the de facto ball of confusion: the semantics
of tabs is what indenting is about, while, using spaces to align code
is a hack.
The reality of programming practice trumps original intent of tab
characters. The tab character and space character are pliable in that
if their use changes their semantics change.
[...]
Yes, as I started programming I also preferred tabs.
And with growing experience on how to handle this in true life
(different editors/systems/languages...) I saw, that
converting the "so fine tabs" was annoying.
The only thing that always worked were spaces.
Tab: nice idea but makes programming an annoyance.
Ciao,
Oliver
achates wrote: A tab is not equivalent to a number of spaces. It is a character
signifying an indent, just like the newline character signifies the end
of a line.
This link posted over in comp.lang.perl.misc expands on that: http://numeromancer.dyndns.org/~timo...scription.html
To me, tabs are like gotos. In the wrong hands, they can be abused.
Novices will do the most hideous things with them. So do we just ban gotos
alogether? No - we structure their use to avoid the most obnoxious
mistakes and live with the rest in a power/abuse tradeoff. Before you
object that modern languages don't use gotos, think again. Break and
continue are merely restricted forms of goto, as are exceptions. Don't
throw the baby out with the bathwater. Make better tools that allow the
good uses and prevent the bad.
--
Edward Elliott
UC Berkeley School of Law (Boalt Hall)
complangpython at eddeye dot net
Duncan Booth wrote: but I prefer editors which keep things
simple. The tab key is particularly prone to excessively complicated
actions, for example the editor I use has the following (not simple at
all, and in fact not even an accurate description of what it does) binding
for the tab key:
<description of strange tab-key binding behaviour>
I'm not familiar with your editor, but if that's its default behaviour
when you hit tab then it sounds neither simple nor intuitive.
You haven't explained why you think there's a problem with having a
character which, in an unambiguous and non-implementation-specific way,
means 'one level of indentation'. In Python, of all languages, it makes
sense to have such a character because 'one level of indentation' is a
syntactical token processed by the interpreter.
But consider this: like all real men, I normally program in hex. Here's
an example of some recent code:
0x66 0x6f 0x72 0x20 0x69 0x74 0x65 0x6d 0x20 0x69 0x6e 0x20 0x6d 0x65
0x6e 0x75 0x3a 0x0d 0x0a 0x09 0x70 0x72 0x69 0x6e 0x74 0x20 0x27 0x73
0x70 0x61 0x6d 0x27 0x0d 0x0a 0x70 0x72 0x69 0x6e 0x74 0x20 0x27 0x6c
0x6f 0x76 0x65 0x6c 0x79 0x20 0x73 0x70 0x61 0x6d 0x27
If I wanted to be girly about it I could use an editor, and it would
probably look like this:
for item in menu:
print 'spam'
print 'lovely spam'
But then if I wanted, I could write my own editor, and make it display
tabs as 'negative indents' from column 40, so that it looks like this:
for item in menu:
print 'spam'
print 'lovely spam'
Guess what: the python interpreter wouldn't know about my strange
editor habits! It would read my file and run just fine. What's more you
can view it with *your preferred indentation display methodology* and
we can both live in harmony!
With spaces for indentation, this just isn't possible, because I have
to conform to your viewing preferences, and that makes me unhappy. Why
would you want to make me unhappy?
Xah Lee wrote: Tabs vs Spaces can be thought of as parameters vs hard-coded values, or
HTML vs ascii format, or XML/CSS vs HTML 4, or structural vs visual, or
semantic vs format. In these, it is always easy to convert from the
former to the latter, but near impossible from the latter to the
former.
Bahaha, looks like someone hasn't thought things through very well.
Spaces, under a mono font, offer greater precision and expressivity in
achieving specific alignment. That expressivity cannot be captured by
tabs.
The difficulty in converting spaces to tabs rests not in any bridgeable
semantic gap, but in the lack of having any way whatsoever to express
using tabs what the spaces are expressing.
It's not /near/ impossible, it's /precisely/ impossible.
For instance, tabs cannot express these alignments:
/*
* C block
* comment
* in a common style.
*/
(lisp
(nested list
with symbols
and things))
(call to a function
with many parameters)
;; how do you align "to" and "with" using tabs?
;; only if "to" lands on a tab stop; but dependence on specific tab
stops
;; destroys the whole idea of tabs being parameters.
To do these alignments structurally, you need something more expressive
than spaces or tabs. But spaces do the job under a mono font, /and/
they do it in a completely unobtrusive way.
If you want to do nice typesetting of code, you have to add markup
which has to be stripped away if you actually want to run the code.
Spaces give you decent formatting without markup. Tabs do not. Tabs are
only suitable for aligning the first non-whitespace character of a line
to a stop. Only if that is the full extent of the formatting that you
need to express in your code can you acheive the ideal of being able to
change your tab parameter to change the indentation amount. If you need
to align characters which aren't the first non-whitespace in a line,
tabs are of no use whatsoever, and proportional fonts must be banished.
achates wrote: With spaces for indentation, this just isn't possible, because I have
to conform to your viewing preferences, and that makes me unhappy. Why
would you want to make me unhappy?
+5 QOTW
--
Edward Elliott
UC Berkeley School of Law (Boalt Hall)
complangpython at eddeye dot net
Kaz Kylheku wrote: If you want to do nice typesetting of code, you have to add markup
which has to be stripped away if you actually want to run the code.
Typesetting code is not a helpful activity outside of the publishing
industry. You might like the results of your typsetting; I happen not
to. You probably wouldn't like mine. Does that mean we shouldn't work
together? Only if you insist on forcing me to conform to your way of
displaying code.
You are correct in pointing out that tabs don't allow for 'alignment'
of the sort you mention:
(lisp
(nested list
with symbols
and things))
But then neither does Python. I happen to think that's a feature.
(And of course you can do what you like inside a comment. That's
because tabs are for indentation, and indentation is meanigless in that
context. Spaces are exactly what you should use then. I may or may not
like your layout, but it won't break anything when we merge our code.)
achates wrote: You haven't explained why you think there's a problem with having a
character which, in an unambiguous and non-implementation-specific way,
means 'one level of indentation'. In Python, of all languages, it makes
sense to have such a character because 'one level of indentation' is a
syntactical token processed by the interpreter.
Because it doesn't mean 'one level of indentation', it means 'move to next
tabstop' and a tabstop isn't necessarily the same as a level of
indentation. In particular a common convention is to have indentations at 4
spaces and tabs expanding to 8 spaces.
Duncan Booth wrote: Because it doesn't mean 'one level of indentation', it means 'move to next
tabstop' and a tabstop isn't necessarily the same as a level of
indentation.
'move to next tabstop' is how your editor interprets a tab character.
'one level of indentation' is how the language parser interprets it.
The two are entirely consistent, in that they are both isomorphic
mappings of the same source file.
In particular a common convention is to have indentations at 4
spaces and tabs expanding to 8 spaces.
Like all space-indenters, you seem to be hung up on the idea of a tab
'expanding' to n spaces. It only does that if you make your editor
delete the tab character and replace it with spaces! Really, that is
the only sense in which your statement makes any sense. If you want
your indentation to have the width of four, eight, or nineteen spaces,
set your tabstops accordingly.
Seriously people, this is about separating the content of a source file
from how it is displayed. It's about letting people work together while
also allowing them to have control over their own environments,
something which is and always has been central to the hacker ethos.
achates wrote: In particular a common convention is to have indentations at 4
spaces and tabs expanding to 8 spaces.
Like all space-indenters, you seem to be hung up on the idea of a tab
'expanding' to n spaces. It only does that if you make your editor
delete the tab character and replace it with spaces! Really, that is
the only sense in which your statement makes any sense. If you want
your indentation to have the width of four, eight, or nineteen spaces,
set your tabstops accordingly.
It is strange. You use many of the same words as me, but they don't make
any sense.
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. 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, and unless I know the convention you are using to display the
tabs I cannot know how many indents are equivalent to a tabstop.
Seriously people, this is about separating the content of a source file
from how it is displayed. It's about letting people work together while
also allowing them to have control over their own environments,
something which is and always has been central to the hacker ethos.
Precisely. Using spaces everywhere allows this, using tabs everywhere
allows this, mixing spaces and tabs is a bad thing. You have to agree a
convention for the project and conform to it. My experience is that 'spaces
only' is more common, but your experience may differ.
achates wrote: Kaz Kylheku wrote:
If you want to do nice typesetting of code, you have to add markup
which has to be stripped away if you actually want to run the code.
Typesetting code is not a helpful activity outside of the publishing
industry.
Be that as it may, code writing involves an element of typesetting. If
you are aligning characters, you are typesetting, however crudely.
You might like the results of your typsetting; I happen not
to. You probably wouldn't like mine. Does that mean we shouldn't work
together? Only if you insist on forcing me to conform to your way of
displaying code.
Someone who insists that everyone should separate line indentation into
tabs which achieve the block level, and spaces that achieve additional
alignment, so that code could be displayed in more than one way based
on the tab size without loss of alignment, is probably a "space cadet",
who has a bizarre agenda unrelated to developing the product.
There is close to zero value in maintaining such a scheme, and
consequently, it's hard to justify with a business case.
Yes, in the real world, you have to conform to someone's way of
formatting and displaying code. That's how it is.
You have to learn to read, write and even like more than one style.
You are correct in pointing out that tabs don't allow for 'alignment'
of the sort you mention:
That alignment has a name: hanging indentation.
All forms of aligning the first character of a line to some requirement
inherited from the previous line are called indentation.
Granted, a portion of that indentation is derived from the nesting
level of some logically enclosing programming language construct, and
part of it may be derived from the position of a character of some
parallel constituent within the construct.
(lisp
(nested list
with symbols
and things))
But then neither does Python. I happen to think that's a feature.
Python has logical line continuation which gives rise to the need for
hanging indents to line up with parallel constituents in a folded
expression.
Python also allows for the possibility of statements separated by
semicolons on one line, which may need to be lined up in columns.
var = 42; foo = 53
x = 2; y = 10
(And of course you can do what you like inside a comment. That's
because tabs are for indentation, and indentation is meanigless in that
context.
A comment can contain example code, which contains indentation.
What, I can't change the tab size to display that how I want? Waaah!!!
(;_;)
Duncan Booth wrote: 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, and unless I know the convention you are using to display the
tabs I cannot know how many indents are equivalent to a tabstop.
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. You do
not need to know my display convention to run my code.
All I can suggest is that you try it out: create a short source file
indented with tabs only, and play around with your editor's tabstop
setting (and make sure it is writing tab characters, not spaces, to the
source file). I promise you the Python interpreter will neither know
nor care what your editor display settings were when you last wrote the
file.
I realise that a lot of code out there uses spaces only. That's
unfortunate, but it doesn't mean we should stop explaining to people
why tab-indenting is a better standard. This is about freedom:
indenting with spaces lets you control over how other people view your
code; indenting with tabs give them that control.
I was once a religous tabber until working on multiple source code sources,
now I am a religious spacer :)
My 2bits worth,
Aaron
achates wrote: Duncan Booth wrote:
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, and unless I know the convention you are using to
display the tabs I cannot know how many indents are equivalent to a
tabstop.
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.
Please be careful how much you trim. I also wrote:
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.
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
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa
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. Seriously people, this is about separating the content of a source
file from how it is displayed. It's about letting people work
together while also allowing them to have control over their own
environments, something which is and always has been central to the
hacker ethos.
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
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa
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)
Ant wrote: 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
Harry George wrote: 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.
--
It's called DOM+XHR and it's *NOT* a detergent!
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.
--
It's called DOM+XHR and it's *NOT* a detergent!
Iain King wrote: 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.
Andy Sy wrote: 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 wrote: 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?
Re-read my post. Note the key word 'in'.
Perhaps if editors colored the background of tab characters differently
from spaces this wouldn't be a problem,
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.
In reality, neither of these are likely
to be implemented any time soon!
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. This thread has been closed and replies have been disabled. Please start a new discussion. |
