Tabs versus Spaces in Source Code
Xah Lee
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/writ/tabs_vs_spaces.html
Eli Gottlieb
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.
Bryan
> 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.
Edward Elliott
> 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
John McMonagle
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.
David Steuber
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.
jmcgill
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.
mystilleef
Mumia W.
> 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/writ/tabs_vs_spaces.html
>
> Xah
> x...@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.
Harry George
> 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
Peter Decker
> 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.
Edward Elliott
> 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.
Brian Quinlan
> 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
Peter Decker
> 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.
gregarican
> 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 :-/
Edward Elliott
> 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.
Peter Decker
> 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.
achates
> 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.
Duncan Booth
> 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.
Sybren Stuvel
> 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
Iain King
sheds...
Iain
Duncan Booth
>> 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.
Sybren Stuvel
> 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.
numeromancer
http://numeromancer.dyndns.org/~timothy/tab-width-independence/description.html
The idea can be extended to other programming languages.
TS
Oliver Bandel
> 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
opalpa@gmail.com opalinski from opalpaweb
> 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
opa...@gmail.com
http://www.geocities.com/opalpaweb/
Pascal Bourguignon
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.
Dale King
> Oh God, I agree with Xah Lee. Someone take me out behind the chemical
> sheds...
>
<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
Oliver Bandel
>>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
Edward Elliott
> 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/~timothy/tab-width-independence/description.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.
achates
>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?
Kaz Kylheku
> 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.
Edward Elliott
> 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
achates
> 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.)
Duncan Booth
> 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.
achates
>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.
Duncan Booth
>>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.
Kaz Kylheku
> 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!!!
(;_;)
achates
>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.
Aaron Gray
now I am a religious spacer :)
My 2bits worth,
Aaron
Duncan Booth
> 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.
Sybren Stuvel
> 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 Stuvel
> 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.
Ant
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
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
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.
--
It's called DOM+XHR and it's *NOT* a detergent!
Andy Sy
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
> > 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.
Ant
> 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."
;-)
--
Nick Craig-Wood <ni...@craig-wood.com> -- http://www.craig-wood.com/nick
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
> >Don't be evil - always configure your editor to
> >convert tabs to true spaces.
"achates" <ayl...@cantab.net> wrote in message
news:1147863377.3...@j73g2000cwa.googlegroups.com...
> Yet another space-indenter demonstrates that problem actually lies with
> people who think that tab == some spaces.
Exactly.
Cheers,
Alan Isaac
achates
>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
> 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.
Andy Sy
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
>> 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.
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
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 <go...@ieee.org>
"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.
--
# p.d.
Bill Pursell
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.
<snip>
> (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
:set ts=<n>
Yeah, that's really tough. vi does just fine handling tabs. vim does
an even better job, with mode-lines, = and :retab.
In my experience, the people who complain about the use
of tabs for indentation are the people who don't know
how to use their editor, and those people tend to use
emacs.
achates
>Emacs guess what's used in the file and allows me to use tabs all the time,
>doing the correct thing...
That sounds like useful behaviour.
Maybe this is an area where modern editors might be able to save us
from ourselves. I'll admit I'm suspicious of relying on editor
functionality - I'm happier if I know I can also use the old-school
methods just in case.. Sometimes adding intelligence to an interface
can be a usability disaster if it makes wrong assumptions about what
you want. But if people are hell-bent on converting tabs to spaces,
maybe it's the best way to accommodate them.
Peter Decker
> In my experience, the people who complain about the use
> of tabs for indentation are the people who don't know
> how to use their editor, and those people tend to use
> emacs.
In my experience, whenever there is a 'religious' issue like this, one
side tends to be quick to pronounce the other as 'evil', and insist
that everyone do things their way, while the other tends to feel
comfortable with people having their own preferences. If I ever find
myself on the side of the former, I always wonder if I'm missing
something obvious.
--
# p.d.
Andy Sy
Is the above an example of how a tab-user exercises 'logic'...?
Besides, I'm not the only dictator here... there are also the:
4-space tabs dictators...
8-space tabs dictators...
etc...
Roy Smith
>In my experience, whenever there is a 'religious' issue like this, one
>side tends to be quick to pronounce the other as 'evil', and insist
>that everyone do things their way,
I don't think people who use tabs are evil. They may be ignorant and
misguided, but they can still have the potential to be saved though
education and persuasion :-)
Bill Pursell
I think you unfairly snipped context on me. I was directly responding
to the assertion that vi is unable to handle tabs well.
As far as tabs vs. spaces, I don't think the spacers are evil, and in
fact I am one for pragmatic reasons. I would much prefer to use
tabs for indentation, especially since in the last few weeks I've
decided to upgrade from 4 to 8, and now all of my spaced code
requires much more effort than ":ts=8" to fix. But in today's world,
it's easier to go with the flow and use spaces.
Andy Sy
> Spaces look like crap, too, when using proportional fonts.
... and people who would even think that using proportional
fonts for viewing/editing source code is anywhere remotely
near being a good idea ...
That's an even more advanced version of the i-think-tabs-are-good
disease... LOL!
Sybren Stuvel
> Now... if you say you SHOULDN'T mix tabs and spaces (indeed this is
> generally regarded as a BAD idea esp. in Python code)
I indeed say so.
> then WHAT THE HECK do you need to use tab characters in the source
> code for anyway (besides saving a measly few bytes) ??!?
To separate layout (how much indentation is used) from semantics (how
many intentation levels).
> Tab characters are EVIL *AND* STUPID.
And someone who needs to resort to all-caps words (which many consider
shouting) needs to relax and use proper arguments.
Peter Decker
> Peter Decker wrote:
> > On 5/17/06, Andy Sy <an...@neotitans.com> wrote:
> >
> >> 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.
>
> Is the above an example of how a tab-user exercises 'logic'...?
Uh, I should know better than to try to educate, but FYI: using the
same argument construction and having it reach an invalid conclusion
suffices to show that the original construction is invalid, and thus
the original conclusion is suspect.
--
# p.d.
Peter Decker
> I think you unfairly snipped context on me. I was directly responding
> to the assertion that vi is unable to handle tabs well.
I was *agreeing* with you. Sorry if that wasn't clear.
--
# p.d.
Andy Sy
I guess this *REALLY* is how a misguided tab user exercises his 'logic':
Syntax replication (e.g. so-called 'argument construction') is enough,
semantics don't matter.
ROTFLMAO!
Peter Decker
My instincts were correct: it is foolhardy to attempt to educate closed minds.
<twitfilter status="on">
--
# p.d.
achates
>I guess this *REALLY* is how a misguided tab user exercises his 'logic':
>Syntax replication (e.g. so-called 'argument construction') is enough,
>semantics don't matter.
That's quite amusing.. you've unwittingly stumbled on a pretty concise
statement of Hilbert's first postulate of formal logic, proved by Godel
in 1930..
>ROTFLMAO!
Indeed.
Andy Sy
Too bad that only applies to /statements phrased in formal
logic/, not to everyday statements expressed in a human language.
Only someone who has run out of sensible arguments or a disingenuous
sophist would try to extend this so-called postulate the way Peter
and you did.
Really... if you *actually* believed that Peter's argument had merit
and he was not merely being facetious, I guess I rest my case
regarding tab users and their 'logical prowess'.
LMAO again.
Andy Sy
>> then WHAT THE HECK do you need to use tab characters in the source
>> code for anyway (besides saving a measly few bytes) ??!?
>
> To separate layout (how much indentation is used) from semantics (how
> many intentation levels).
Like I said, you'll *NEVER* get that fancy shmancy 'semantic indentation'
idea to work properly in the most basic utilities which have the 8-space tabs
assumption hardcoded in them.
Code with anything other than 8-space tabs will *NEVER* display
properly using everyday unix utilities such as less and cat. But then,
8-space tabs are just too wide to be practical, thus the simple
conclusion I have reached: JUST STOP USING THEM.
Heck, all those who actually believe that make's requirement of an
invisible tab as a 'semantic' marker was a good idea raise their
hands...! <rolling-eyes-to-high-heaven>
>> Tab characters are EVIL *AND* STUPID.
>
> And someone who needs to resort to all-caps words (which many consider
> shouting) needs to relax and use proper arguments.
I know when I'll be able to relax... when I no longer need to waste time
dealing with those stupid tabs in source code!!!
;-)
Sybren Stuvel
> indentation' idea to work properly in the most basic utilities which
> have the 8-space tabs assumption hardcoded in them.
Fair enough. How much code is viewed with less and cat, and how much
is viewed using smart viewers/editors? I think the majority is viewed
using the latter.
Carl J. Van Arsdall
> Andy Sy enlightened us with:
>
>> Like I said, you'll *NEVER* get that fancy shmancy 'semantic
>> indentation' idea to work properly in the most basic utilities which
>> have the 8-space tabs assumption hardcoded in them.
>>
>
> Fair enough. How much code is viewed with less and cat, and how much
> is viewed using smart viewers/editors? I think the majority is viewed
> using the latter.
>
vi. I don't know why so many people have so many issues with tabs, they
really aren't that difficult to work with and I think make life a little
easier when working on code with multiple people. You can setup your
environment to make tabs look like you want your code to look, your team
members can do tabs their way, and in the end the indentation levels all
work out fine.
People want to fight tooth and nail over this debate. But its really
not worth it. Get an editor that doesn't completely suck and you won't
have problems.
.c
--
Carl J. Van Arsdall
cvana...@mvista.com
Build and Release
MontaVista Software
achates
>Code with anything other than 8-space tabs will *NEVER* display
>properly using everyday unix utilities such as less and cat.
less -x<tabstop> does what you want.
Edward Elliott
> Jorge Godoy wrote
>
>>Emacs guess what's used in the file and allows me to use tabs all the
>>time, doing the correct thing...
>
> That sounds like useful behaviour.
vim can do it to.
http://www.vim.org/scripts/script.php?script_id=1171
--
Edward Elliott
UC Berkeley School of Law (Boalt Hall)
complangpython at eddeye dot net
Edward Elliott
> Andy Sy enlightened us with:
>> Like I said, you'll *NEVER* get that fancy shmancy 'semantic
>> indentation' idea to work properly in the most basic utilities which
>> have the 8-space tabs assumption hardcoded in them.
>
> Fair enough. How much code is viewed with less and cat, and how much
> is viewed using smart viewers/editors? I think the majority is viewed
> using the latter.
Just for the sake of completeness:
cat file |sed 's/\t/ /g'
less -x4 file
vim ~/bin.cat
#!/bin/sh
cat "$@" |sed 's/\t/ /g'
:wq
alias less='less -x4'
63q2...@sneakemail.com
shift-alt-i it faintly displays all spaces as little dots and all tabs
as '>>' (but using the single ascii character instead). I use tabs to
indent blocks, then if stuff within a block needs to be aligned (such
as if statements or dictionaries), I used spaces. So this is mixing
tabs and spaces, but the indentation level is always tabs.
Andy Sy
Ok, that tip certainly counts for something. This is
definitely going to make viewing tabbed code suck much
less (although you still have to guess the tab setting
using trial and error).
Next major objection then, how can one practically use 'tabs as
semantic indentation' without screwing up formatting of code like
the below??
def sqlcall():
cursor.execute('select id, item, amount, field4, field5, field6'+
'from table1 where amount>100')
... if you change the tabsize then the 3rd line will no longer
properly align with the start of the quote in the 2nd line.
The 3rd line makes use of _arbitrary_, not semantic indentation.
Because you cannot count on indentation to be semantics-driven on every
single line, you _will_ end up mixing semantic and arbitrary indentation
and thus the whole notion of being able to use tabs as 'semantic
indentation' is *still untenable*.
There is JUST NO PRACTICAL USE FOR TABS.
Carl J. Van Arsdall
> definitely going to make viewing tabbed code suck much
> less (although you still have to guess the tab setting
> using trial and error).
>
>
> Next major objection then, how can one practically use 'tabs as
> semantic indentation' without screwing up formatting of code like
> the below??
>
>
> def sqlcall():
> cursor.execute('select id, item, amount, field4, field5, field6'+
> 'from table1 where amount>100')
>
>
start of the quote then use a couple spaces? Then the tabs would work
just fine and you could still have your pretty line.
Andy Sy
> 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.
>
> def foo():
> ->query = """SELECT *
> -> .......FROM sometable
> -> .......WHERE condition"""
>
> That would solve it. Tabs for indentation, spaces for spacing.
>
> Ed
Ok, this is a somewhat workable solution.
Cons:
1) You have to be more conscientious regarding how many tabs
you use at the beginning of a line. If your text editor
does not display tabs explicitly (SciTE can), it can be
a *REAL* hassle.
2) Because you have to use all pure spaces after the proper
# of tabs, you will often end up having to type a lot
of them compared to if your tab key generated pure spaces.
Pro:
1) Happily, you do get your 'semantic indentation' so people can
dynamically change the indentation-size they want to view your
code with.
You do need everyone to understand 1 thing: NEVER use tab characters
(and consequently the tab key) for anything EXCEPT semantic indentation.
Big question though: is the above guaranteed to work nicely in all
situations in python?
Also, in free-format languages like C, Java, C#, the temptation to mix
semantic and arbitrary indentation might be just too great for sloppy
programmers.
If anyone wants to use tabs, I think the above is the ONLY right way
to use them and it also happily eliminates any arguments over how
many spaces you should use for your tab setting.
If ALL tab users followed this convention, I will happily consider
myself agnostic... ;-)
Now, on to the next holy war... date formats....
ANY OTHER FORMAT BESIDES ISO YYYYMMDD (but it's ok to put dashes
in between or use word MMM instead of numerical MM) IS *EVIL* AND
*MISGUIDED*!
Andy Sy
>> Next major objection then, how can one practically use 'tabs as
>> semantic indentation' without screwing up formatting of code like
>> the below??
>>
>>
>> def sqlcall():
>> cursor.execute('select id, item, amount, field4, field5, field6'+
>> 'from table1 where amount>100')
>>
>>
> Why couldn't you tab your third line over as close as possible to the
> start of the quote then use a couple spaces? Then the tabs would work
> just fine and you could still have your pretty line.
This will break if someone tries to view my code using different
tab settings from the one I'm using.
Dave Hansen
<nob...@127.0.0.1> wrote:
>Sybren Stuvel wrote:
>
>> Andy Sy enlightened us with:
>>> Like I said, you'll *NEVER* get that fancy shmancy 'semantic
>>> indentation' idea to work properly in the most basic utilities which
>>> have the 8-space tabs assumption hardcoded in them.
>>
>> Fair enough. How much code is viewed with less and cat, and how much
>> is viewed using smart viewers/editors? I think the majority is viewed
>> using the latter.
>
>Just for the sake of completeness:
>
>cat file |sed 's/\t/ /g'
That doesn't always work. If you don't see why, you don't understand
my objection to TAB characters in text files.
>less -x4 file
That will work. As long as the creator of file used four-space TABs,
anyway...
Regards,
-=Dave
--
Change is inevitable, progress is not.
Carl J. Van Arsdall
regardless of the tabstop setting.
Dave Hansen
Arsdall" <cvana...@mvista.com> wrote:
>Andy Sy wrote:
>> Carl J. Van Arsdall wrote:
>>
>>
>>>> Next major objection then, how can one practically use 'tabs as
>>>> semantic indentation' without screwing up formatting of code like
>>>> the below??
>>>>
>>>>
>>>> def sqlcall():
>>>> cursor.execute('select id, item, amount, field4, field5, field6'+
>>>> 'from table1 where amount>100')
>>>>
>>>>
>>>>
>>> Why couldn't you tab your third line over as close as possible to the
>>> start of the quote then use a couple spaces? Then the tabs would work
>>> just fine and you could still have your pretty line.
>>>
>>
>>
>> This will break if someone tries to view my code using different
>> tab settings from the one I'm using
>>
>Uh, no it won't. It should be read in as "one tab and two spaces"
>regardless of the tabstop setting.
Think about it a little harder. What does that "one tab" mean?
Assume the code was written by someone using 4-space tabs. To them,
the code is:
def sqlcall():
--->cursor.execute('select id, item, amount, field4, <etc>
--->--->--->--->...'from table1 where amount>100')
(where -------> represents an 4-space tab and . represents a space)
Which looks fine. But if I then load the code into my editor with
3-space tabs, it looks like:
def sqlcall():
-->cursor.execute('select id, item, amount, field4, <etc>
-->-->-->-->...'from table1 where amount>100')
Then my colleage loads it into his editor with 8-space tabs, and it
looks like (assuming I didn't change it to make it look reasonable):
def sqlcall():
------->cursor.execute('select id, item, amount, field4, <etc>
------->------->------->------->...'from table1 where amount>100')
In each case the second line has four TABs and three spaces. But only
with the original TAB settings does it line up properly.
The only solution (as posted elsewhere) is to somehow enforce tabs for
indentation and spaces for spacing:
def sqlcall():
--->cursor.execute('select id, item, amount, field4, <etc>
--->...............'from table1 where amount>100')
However, to twist an observation I've read about C++, while it's
clearly possible to use TABs in a sensible manner like this, it seems
that no one does. Or at least, it doesn't last much beyond the
original author of the code...
achates
>That will work. As long as the creator of file used four-space TABs,
>anyway...
That sentence has no meaning. There is no such thing as a four-space
tab.
achates
>def sqlcall():
> cursor.execute('select id, item, amount, field4, field5, field6'+
> 'from table1 where amount>100')
Lines two and three (a continuation line) are both at a syntactic
indentation level of 1. Therefore they should both start with a tab.
(Though actually indentation is ignored for continuation lines so you
only need to preserve the indentation if you want alignment.)
Then you can add spaces to align the function arguments.
def sqlcall():
<tab>cursor.execute('select id, item, amount, field4, field5, field6'+
<tab><---spaces---->'from table1 where amount>100')
I prefer not to bother with alignment like this, but if you do want to
align things, you use spaces. Indenting is done with tabs; alignment
with spaces.
Carl J. Van Arsdall
different (which I know invalidates my original point), but it certainly
doesn't break code.
I don't really use multiline strings in my code, but I find when working
with other people I prefer the tab method. For nothing else other than
"my indent is 2 whereas my coworker's is 4" and the use of tabs allows
us to throw things around much more easily without either of us having
to compromise on personal preference.
.c
--
Carl J. Van Arsdall
cvana...@mvista.com
achates
>However, to twist an observation I've read about C++, while it's
>clearly possible to use TABs in a sensible manner like this, it seems
>that no one does.
I think it's evident from this thread that quite a few people do that,
judging by the fact that my previous post explaining this was doubly
redundant by the time I got round to sending it.
Also we should remember that in Python, alignment only applies to
continuation lines and comments. Logical lines (the vast majority of
lines in a source file) can't be arbitraily aligned.
Sybren Stuvel
> Assume the code was written by someone using 4-space tabs. To them,
> the code is:
>
> def sqlcall():
> --->cursor.execute('select id, item, amount, field4, <etc>
> --->--->--->--->...'from table1 where amount>100')
>
> (where -------> represents an 4-space tab and . represents a space)
That would be stupid indeed. It would indeed fix the tabstops at every
4 characters to keep the layout.
But generally, I don't do layout like that. I'd do:
--->cursor.execute(
--->--->--->'select id, item, amount, field4, <etc>
--->--->--->'from table1 where amount>100'
--->)
Which keeps looking fine, no matter what tab size, and without mixing
tabs and spaces.
Just because people can use tabs to make things suck,
doesn't mean the tabs are evil.
Edward Elliott
> On Wed, 17 May 2006 17:28:26 GMT in comp.lang.python, Edward Elliott
>>Just for the sake of completeness:
>>
>>cat file |sed 's/\t/ /g'
>
> That doesn't always work. If you don't see why, you don't understand
> my objection to TAB characters in text files.
>
>>less -x4 file
>
> That will work. As long as the creator of file used four-space TABs,
> anyway...
I fail to see why less 'will work' but cat 'doesn't always work'. The net
effect of both is the same. Unless you're in some weird place that pipes
aren't allowed, these should be equivalent:
cat file |sed 's/\t/ /g' |less
less -x4 file
Now if you're talking about the conversion altering the data's semantics,
that's a separate issue that has nothing to do with unix utilities and
everything to do with the file formatting. In that case, I'll simply refer
you to the rest of this thread for discussion.
glomde
>
> --->cursor.execute(
> --->--->--->'select id, item, amount, field4, <etc>
> --->--->--->'from table1 where amount>100'
> --->)
>
>Which keeps looking fine, no matter what tab size, and without mixing
>tabs and spaces.
>
But If you work in a team it is kind of hard to make sure that
everybody use tabs and not spaces. And it is not very easy to spot
either. The same is valid if somebody use your code or you
want to import somebody elses code.
Carl J. Van Arsdall
>>
>
> But If you work in a team it is kind of hard to make sure that
> everybody use tabs and not spaces. And it is not very easy to spot
> either.
>
uses spaces and not tabs".
I think we've just about beat this discussion to death... nice work
everyone!
--
Carl J. Van Arsdall
cvana...@mvista.com
Edmond Dantes
> opa...@gmail.com opalinski from opalpaweb wrote:
...
> 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
It all depends on your editor of choice. Emacs editing of Lisp (and a few
other languages, such as Python) makes the issue more or less moot. I
personally would recommend choosing one editor to use with all your
projects, and Emacs is wonderful in that it has been ported to just about
every platform imaginable.
The real issue is, of course, that ASCII is showing its age and we should
probably supplant it with something better. But I know that will never fly,
given the torrents of code, configuration files, and everything else in
ASCII. Even Unicode couldn't put a dent in it, despite the obvious growing
global development efforts. Not sure how many compilers would be able to
handle Unicode source anyway. I suspect the large majority of them would
would choke big time.
Oh well...
--
-- Edmond Dantes, CMC
And Now for something Completely Different:
http://gift-basket.prosperitysprinkler.com
http://sewing-machine.womencraft.com
http://coveralls.whiteboystuff.com
http://eyewear.blackboystuff.com
http://dinette.funiturenow.com
http://wheels.whiteboystuff.com
http://patio.funiturenow.com
Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com
William Studenmund
Hash: SHA1
On May 17, 2006, at 8:46 PM, Edward Elliott wrote:
> Dave Hansen wrote:
>
>> On Wed, 17 May 2006 17:28:26 GMT in comp.lang.python, Edward Elliott
>>> Just for the sake of completeness:
>>>
>>> cat file |sed 's/\t/ /g'
>>
>> That doesn't always work. If you don't see why, you don't understand
>> my objection to TAB characters in text files.
>>
>>> less -x4 file
>>
>> That will work. As long as the creator of file used four-space TABs,
>> anyway...
>
> I fail to see why less 'will work' but cat 'doesn't always work'.
> The net
> effect of both is the same. Unless you're in some weird place that
> pipes
> aren't allowed, these should be equivalent:
I don't think that cat is the problem, it's sed.
The problem is that tabs take you to the next tab stop, they don't
expand to a fixed number of spaces.
Consider the strings "\t\t", "\t \t", and "\t \t". With everything
except one- or two-space tab settings (less -x1 or less -x2), the
spaces haven't moved us past a tab stop, so the \t after them takes
us to the same tab stop in all cases.
Take care,
Bill
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFEa62XDJT2Egh26K0RAhFUAJ0WWgTRS570DsHAUl0oij47qNoIfgCgiVyV
9vZQUBAOspWLfuom2Scy4MY=
=wmWa
-----END PGP SIGNATURE-----
achates
> 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
explain why tabs give are a good idea, facing a whole raft of others
spouting stuff like:
'mixing spaces and tabs is bad so use spaces only'
'tabs are x spaces and I like to use y spaces'
'tabs are bad end of story'
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
that.
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.
But unfortunately the situation is worse than that: tab indentation
needs to be actively defended. Most of the coding 'style guides' you'll
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.
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.
Terry Hancock
>Dave Hansen wrote:
>
>
>I fail to see why less 'will work' but cat 'doesn't always work'.
>
The distinction is not in the choice of program, but in the
way it is being used...
>The net
>effect of both is the same. Unless you're in some weird place that pipes
>aren't allowed, these should be equivalent:
>
>cat file |sed 's/\t/ /g' |less
>less -x4 file
>
>
Nope. To demonstrate, I will use "T" to represent tab characters
and "S" to represent spaces (I think this will be
a lot easier to read):
In a properly formatting program, with tabstops at intervals of 4:
A=
"""
SSTSTdefSspam(self,Sfoo):
STTSSSSbarS=S1/foo
TTSTreturnSbar
"""
and
B =
"""
TTdefSspam(self,Sfoo):
SSSSSSSSSSSSbarS=S1/foo
TTTreturnSbar
"""
should render exactly the same (i.e. like the following):
A=B=
"""
def spam(self, foo):
bar = 1/foo
return bar
"""
However, if we have tabstop set to 8 (the usual default),
then they will render differently:
A=
"""
def spam(self, foo):
bar = 1/foo
return bar
"""
B=
"""
def spam(self, foo):
bar = 1/foo
return bar
"""
(both are syntax errors, of course).
Presumeably, the "x" option to less will correctly handle
tabs (I didn't know about that -- thanks, BTW), but your
sed substitution doesn't "jump to the next tabstop" when
it hits a tab, it always adds a fixed number of spaces. So
it mangles the code too:
A=
"""
def spam(self, foo):
bar = 1/foo
return bar
"""
B=
"""
def spam(self, foo):
bar = 1/foo
return bar
"""
>Now if you're talking about the conversion altering the data's semantics,
>that's a separate issue that has nothing to do with unix utilities and
>everything to do with the file formatting. In that case, I'll simply refer
>you to the rest of this thread for discussion.
>
>
Now, of course, the data I provide is nasty, mean, poorly-formatted
data, abhorable by space-zealots and tab-libertines alike (;-)), but the
point is, unless you have set up your editor to syntax color spaces
and tabs differently, you won't see the difference in the original
editor.
Cheers,
Terry
--
Terry Hancock (han...@AnansiSpaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com