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/
May 15 '06
135  7316 
> Not that it's relevant, but I've never actually encountered anyone who mixed tabs and spaces.. I've lived a sheltered life I guess.
It's not individuals using a mixture, but when working in a development
team of some kind. Consider person A who writes a file using spaces for
indent. Person B then edits that file, adding a few lines of code,
indenting using tabs. It could soon get messy!
Ant <an****@gmail.com> 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.
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
achates wrote: 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:
Sorry to hear that. You should try using an editor that's easier for
you.
> Andy Sy wrote: Don't be evil - always configure your editor to
convert tabs to true spaces.
"achates" <ay****@cantab.net> wrote in message
news:11**********************@j73g2000cwa.googlegr oups.com... Yet another space-indenter demonstrates that problem actually lies with
people who think that tab == some spaces.
Exactly.
Cheers,
Alan Isaac
>Hitting the spacebar like a madman? If you have a sensible editor then at the start of a line you press tab once
True! but normally if I'm editing someone else's code then I'm only
making small changes and so can't be bothered to temporarily cripple my
editor. If I'm merging my code with someone else's space-indented code
then piping through sed 's/TAB/SPACES' does the trick.
achates enlightened us with: True! but normally if I'm editing someone else's code then I'm only
making small changes and so can't be bothered to temporarily cripple my
editor. If I'm merging my code with someone else's space-indented code
then piping through sed 's/TAB/SPACES' does the trick.
I just type 'retab' in my editor, and everything is fine. I use VIM,
which is great for tab/space management.
Sybren
--
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
If tabs are easily misunderstood, then they are a MISfeature
and they need to be removed. From the Zen of Python:
"Explicit is better than implicit..."
"In the face of ambiguity, refuse the temptation to guess..."
"Special cases aren't special enough to break the rules..."
--
It's called DOM+XHR and it's *NOT* a detergent!
achates wrote: 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.
--
It's called DOM+XHR and it's *NOT* a detergent!
achates wrote: Hitting the spacebar like a madman? If you have a sensible editor then at
the start of a line you press tab once
True! but normally if I'm editing someone else's code then I'm only
making small changes and so can't be bothered to temporarily cripple my
editor. If I'm merging my code with someone else's space-indented code
then piping through sed 's/TAB/SPACES' does the trick.
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.
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.
--
# p.d.
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.
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.
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.
On 17 May 2006 06:51:19 -0700, Bill Pursell <bi**********@gmail.com> wrote: 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.
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'...?
Besides, I'm not the only dictator here... there are also the:
4-space tabs dictators...
8-space tabs dictators...
etc...
--
It's called DOM+XHR and it's *NOT* a detergent!
Peter Decker <py******@gmail.com> wrote: 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 :-)
Peter Decker wrote: On 17 May 2006 06:51:19 -0700, Bill Pursell <bi**********@gmail.com> wrote:
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.
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.
Peter Decker wrote: 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!
Andy Sy enlightened us with: 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.
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
On 5/17/06, Andy Sy <an**@neotitans.com> wrote: 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.
On 17 May 2006 07:14:33 -0700, Bill Pursell <bi**********@gmail.com> wrote: 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.
Peter Decker wrote: On 5/17/06, Andy Sy <an**@neotitans.com> wrote: 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.
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!
--
It's called DOM+XHR and it's *NOT* a detergent!
On 5/17/06, Andy Sy <an**@neotitans.com> wrote: 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.
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!
My instincts were correct: it is foolhardy to attempt to educate closed minds.
<twitfilter status="on">
--
# 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.
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.
achates wrote: 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.
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.
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.
Sybren Stuvel wrote: 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!!!
;-)
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.
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
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.
Really though, he's got a good point. I'm typically viewing code in
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 cv*********@mvista.com
Build and Release
MontaVista Software
Andy Sy: 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.
achates wrote: 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
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'
less -x4 file
vim ~/bin.cat
#!/bin/sh
cat "$@" |sed 's/\t/ /g'
:wq
alias less='less -x4'
--
Edward Elliott
UC Berkeley School of Law (Boalt Hall)
complangpython at eddeye dot net
I use Edit Plus for all my text-editing needs. With a simple
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.
achates wrote: Andy Sy: 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.
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.
--
It's called DOM+XHR and it's *NOT* a detergent!
Andy Sy wrote: achates wrote:
Andy Sy:
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.
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')
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.
..c
--
Carl J. Van Arsdall cv*********@mvista.com
Build and Release
MontaVista Software
Ed Singleton wrote: 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*!
--
It's called DOM+XHR and it's *NOT* a detergent!
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.
--
It's called DOM+XHR and it's *NOT* a detergent!
On Wed, 17 May 2006 17:28:26 GMT in comp.lang.python, Edward Elliott
<no****@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.
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.
..c
--
Carl J. Van Arsdall cv*********@mvista.com
Build and Release
MontaVista Software
On Wed, 17 May 2006 12:02:46 -0700 in comp.lang.python, "Carl J. Van
Arsdall" <cv*********@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...
Regards,
-=Dave
--
Change is inevitable, progress is not.
Dave Hansen wrote: 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.
Andy Sy wrote: 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.
Dave Hansen wrote: On Wed, 17 May 2006 12:02:46 -0700 in comp.lang.python, "Carl J. Van
Arsdall" <cv*********@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')
Ah, good point. I was referring to it "breaking code". It may look
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 cv*********@mvista.com
Build and Release
MontaVista Software
Dave Hansen wrote: 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.
Dave Hansen enlightened us with: 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.
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
Dave Hansen wrote: On Wed, 17 May 2006 17:28:26 GMT in comp.lang.python, Edward ElliottJust 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.
--
Edward Elliott
UC Berkeley School of Law (Boalt Hall)
complangpython at eddeye dot net
> 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.
Which only works fine only if you are the one only editing the file.
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.
glomde wrote:
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 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!
--
Carl J. Van Arsdall cv*********@mvista.com
Build and Release
MontaVista Software
Oliver Bandel wrote: op****@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
-----BEGIN PGP SIGNED MESSAGE-----
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)
iD8DBQFEa62XDJT2Egh26K0RAhFUAJ0WWgTRS570DsHAUl0oij 47qNoIfgCgiVyV
9vZQUBAOspWLfuom2Scy4MY=
=wmWa
-----END PGP SIGNATURE-----
Carl J. Van Arsdall wrote: The converse can also be said, "it's difficult to make sure everyone
uses spaces and not tabs".
I think we've just about beat this discussion to death... nice work
everyone!
Yeah - we've got to the repeating ourselves stage.
But that's the problem with this issue: it's really hard to get the
space-indenters to actually think about it and to address what is being
said. Every time it comes up, there's always a few people trying to
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.
Edward Elliott wrote: 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 (ha*****@AnansiSpaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com This thread has been closed and replies have been disabled. Please start a new discussion. |
