Tabs versus Spaces in Source Code

6

63q2o4i02

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.
 
A

Andy Sy

achates said:
Andy Sy:

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.
 
C

Carl J. Van Arsdall

Andy said:
achates wrote:




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
(e-mail address removed)
Build and Release
MontaVista Software
 
A

Andy Sy

Ed said:
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*!
 
A

Andy Sy

Carl said:
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.
 
D

Dave Hansen

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
 
C

Carl J. Van Arsdall

Andy said:
Carl J. Van Arsdall wrote:




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
(e-mail address removed)
Build and Release
MontaVista Software
 
D

Dave Hansen

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
 
A

achates

Dave said:
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.
 
A

achates

Andy said:
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.
 
C

Carl J. Van Arsdall

Dave said:
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
(e-mail address removed)
Build and Release
MontaVista Software
 
A

achates

Dave said:
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.
 
S

Sybren Stuvel

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
 
E

Edward Elliott

Dave said:
That doesn't always work. If you don't see why, you don't understand
my objection to TAB characters in text files.


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.
 
G

glomde

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.
 
C

Carl J. Van Arsdall

glomde said:
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
(e-mail address removed)
Build and Release
MontaVista Software
 
E

Edmond Dantes

Oliver said:
(e-mail address removed) 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
 
W

William Studenmund

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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-----
 
A

achates

Carl said:
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.
 
T

Terry Hancock

Edward said:
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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,902
Latest member
Elena68X5

Latest Threads

Top