Tabs -vs- Spaces: Tabs should have won.

[Andrew Berg]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

What is the difference between indentation and alignment? Well,
indentation works with tabs, alignment not.

The use of spaces for indentation is as much of a hack as the use of
tabs for alignment is. Not everyone agrees on how many spaces an indent
should be (whether an indent is a tab or a space-tab), which is a good
reason to use tabs. In fact, spaces have absolutely /no/ advantage over
tabs when it comes to pure indentation. It may be possible to configure
an editor to compensate using space-tabs (and perhaps even detect the
length of indents, changing the number of spaces to conform to what the
reader thinks is the right number of spaces per indent), but this is all
to make a pretty delicate environment just to be even with tabs.
On the flip side, tabs can't maintain alignment because again, not
everyone agrees on how big a tab should be. This is a good reason to use
spaces. Using tabs for indentation and spaces for alignment solves the
problem. I really can't think of any problems this would cause that
aren't superficial.

The author's conclusion "simply just use what ever you want for
indenting, but use spaces for aligning" leaves only two choices for
Python programmers: use spaces for indenting or don't align.

It's possible to indent with tabs and align with spaces in Python; see
my earlier post.

- --
CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0
PGP/GPG Public Key ID: 0xF88E034060A78FCB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAwAGBQJOIp8PAAoJEPiOA0Bgp4/LpjYIAIa+Qpw+1Uhsdv8R3NkH4yat
h7axOgwpq2SqbU9KsJpmJbC737C2JWj3GrCzkSfExjlrG2Wv5qB7U5hgFbJVeTU/
1paBZtXP0BZgXLEeZwlIKJDT3HF28sj7GCMFoP6KhX0v7oe7BsaRyriIBAQWX4Hh
p8NrMfr16tkGQXFmTPyu5UHdiCX35/9ywR1hw96h4H1J6sht1Q6N47Xx4EI4DN/X
eU5wY7qrJPjinYD7N3uQGpRhHKjTIAWRSPxFtN6voP9Y+6KGPH+e2eDFV06h8Hi1
/tPQtbfWROdN1c10TL57FDBqW+Q32gMB3z60/XMPWhB5Mz0a/dFLou5bdDhvtvc=
=w8GN
-----END PGP SIGNATURE-----

 

[Thorsten Kampe]

* Andrew Berg (Sun, 17 Jul 2011 03:36:31 -0500)

Not everyone agrees on how many spaces an indent should be (whether an
indent is a tab or a space-tab), which is a good reason to use tabs.

Not everyone who doesn't agree on indent size actually cares enough
about indent size - especially in someone else's code. I'd say it's
probably rather the majority making this whole debate artificial.

I like my indent four spaces. If you like eight, wonderful, I don't
care, it's your code. If I want to use your code in my own, I completely
have to reformat your code anyway. And if we work on a project together,
we have to agree on formatting anyway, the indent size being the least
important one.

This whole debate is artificial.

Using tabs for indentation and spaces for alignment solves the
problem. I really can't think of any problems this would cause that
aren't superficial.

Sorry, you didn't understand my point. My point is: the distinction
between indentation and alignment is superficial. Indentation /is/
exactly the same as alignment.

Thorsten

 

[Anders J. Munch]

I can't fathom why 8 position tabs were *ever* the default, let alone why
they are still the default.

That's because they were not invented as a means for programmers to vary
indentation.

Originally, tabs were a navigation device: When you press the tab key, you skip
ahead to the next tab column. The notion that whitespace characters are
inserted into the text would have been very alien to someone using text
processing software anno 1970. Same thing with space and enter; on typewriters
the space bar doesn't "type" anything onto the paper, it moves to the next
column, and that thinking carried over to computers.

The reason the tab stop is a full 8 positions: for faster navigation. If it
were 3 positions, it would take forever to skip from the start of line to column
60. You'd appreciate that, if you were e.g. writing a fiduciary report with
some text to the left and two number columns to the right, back in the day
before spreadsheets and word processor tables. Skip a column or two too far?
Adjust by backspacing (another navigation key).

As for why 8 is still the default - well, what else should it be? 2, 3, 4, 5? I
for one am thankful that we have so far been spared the flamewar armegeddon of
all the world's programmers trying to agree on that.

Just like in the old days

regards, Anders

 

[Thorsten Kampe]

* Andrew Berg (Sun, 17 Jul 2011 05:02:22 -0500)

How is indent size unimportant with regard to formatting?

Take some code or yours and format it with three and with six spaces.
Then you will see how unimportant it is: it looks virtually the same.

Or as I've written in another posting:
"There is for instance maximum line length, the number of empty lines,
the author's method of alignment, spaces between the equals sign and so
on. These are all much more "dominant" in the source code and none of
this is left for the reader's disposition.

Compare for instance

variable = 11
anothervariable = 22

def whatever (prettylong = 1,
alsoprettylong = 22,
anotherone = 33):
pass

to

variable=11
anothervariable=22
def whatever (prettylong=1, alsoprettylong=22, anotherone=33):
pass"

Only if no one cares about your code.

Only if you don't care about indent length - which I again state, most
people (probably) don't.

It's also worth mentioning that some people have an almost religious
fervor when it comes to spaces and tabs.

I know. These are people like rantingrick who start artificial threads
like this with artificial problems like tabs versus spaces to liberate
the common coder.

I still don't understand. Whitespace to the left of an assignment to
signify an indent and whitespace around operators to align values (in
a multi-line assignment) are not the same.

When I'm (consistently, of course) indenting code, I'm aligning it. When
I'm aligning code, I do this by indenting it, see for instance...

firstvariable = 11
variable = 111

firstvariable = 22
variable = 222

The second "=" and the "222" is indented.

Or your example:
setup(
name = 'Elucidation',
version = '0.0.1-WIP',
py_modules = ['elucidation'],
author = 'Andrew Berg',
author_email = '(e-mail address removed)',
url = '',
platforms = 'Windows',
description = 'Provides a class for storing information on
multimedia files that are to be converted or remuxed and methods to
convert and remux using popular tools.'
)

The keywords are aligned by indenting. In the "left of an assignment"
case it makes a difference for the Python compiler, in the alignment
case it doesn't. In both cases, it makes a difference to the human who
indents/aligns to group similar things and blocks.

Thorsten

 

[Dotan Cohen]

If you're masochistic, maybe. Do you find fixed-width fonts ugly?

I don't find that fixed-width fonts are ugly, but variable-width fonts
sure are more of a pleasure. And with code-colouring in any good IDE,
there is no real need to have the dot or other tiny characters jump
out and announce their presence. So long as the indentation lines up
(which it does, with tabs or spaces) then I do not see any problem
with variable-width.

What are the counter-arguments?

I
really would like to know why anyone would use a non-fixed-width font
for programming.
Aesthetics.

I use Courier New.

Have you looked at the Droid fixed-width fonts? Very nice, and easy to
distinguish 0 from o or O.

 

[rusi]

I don't find that fixed-width fonts are ugly, but variable-width fonts
sure are more of a pleasure. And with code-colouring in any good IDE,
there is no real need to have the dot or other tiny characters jump
out and announce their presence. So long as the indentation lines up
(which it does, with tabs or spaces) then I do not see any problem
with variable-width.

What are the counter-arguments?


Aesthetics.

Its more (or less depending...) than just aesthetics. Its about
optimization.
On a fixed width font an 'i' is as wide as an 'm' as a '.'
This means that a fwf is either a unreasonably small or the lines are
too long.

[Note: I use only fwf because all the tools I know/use/tried are
broken for vwf]

 

[Thorsten Kampe]

* Dotan Cohen (Sun, 17 Jul 2011 14:11:40 +0300)

So long as the indentation lines up (which it does, with tabs or
spaces) then I do not see any problem with variable-width.

What are the counter-arguments?

Alignment doesn't line up.

Thorsten

 

[Thomas 'PointedEars' Lahn]

* Andrew Berg (Sun, 17 Jul 2011 05:02:22 -0500)

When I'm (consistently, of course) indenting code, I'm aligning it. When
I'm aligning code, I do this by indenting it, see for instance...

firstvariable = 11
variable = 111

firstvariable = 22
variable = 222

The second "=" and the "222" is indented.

You might want to check your English dictionary. Indenting is commonly
understood in typography as "To begin (a line or lines) at a greater or less
distance from the margin"¹. In particular, in computer programming it
usually means that there is, at most, whitespace on the left of the text.²
In that sense, the above is _not_ indentation (or indenting), as neither
"variable" nor "variable =" consist only of whitespace. It is only
aligning.³

HTH

_______
¹ <http://en.wiktionary.org/wiki/indenting>
² <http://en.wikipedia.org/wiki/Indent_style>
³ <http://en.wiktionary.org/wiki/aligning>

 

[Thomas 'PointedEars' Lahn]

I am also a recent spaces-to-tabs convert. One of the reasons is that
I've discovered that programing in a non-fixed width font is a real
pleasure, but the spaces are too narrow. Tabs alleviate that.

Not using a fixed-width font avoids this problem and others in the first
place.

I'm still looking for the perfect programming font. Suggestions welcomed.

I can recommend Consolas (Windows) or Inconsolata (elsewhere), which are
designed for programming and are near perfect in that regard. However, I
have decided for "Deja Vu Sans Mono" for reading and writing Usenet articles
because it supports more Unicode characters and can be sized appropriately
for running text.

But, all of them are fixed-width fonts. I do not understand how you can
consider using a non-fixed-width font in programming "a real pleasure" as
many them show a lot of ambiguities in source code. Take for example the
lowercase "l" (el) vs. the capital "I" (ai) vs. the "|" (pipe) character,
or the "0" (zero) vs. the capital "O" (oh) character in Arial.

 

[TheSaint]

but if somebody later tries to edit the
file using 8-space tabs

I came across this and I like to put a note on top of the script
to remember to modify it accordingly.

 

[gene heskett]

I am also a recent spaces-to-tabs convert. One of the reasons is that
I've discovered that programing in a non-fixed width font is a real
pleasure, but the spaces are too narrow. Tabs alleviate that.

I'm still looking for the perfect programming font. Suggestions
welcomed.

When you find it Dotan, let me know, I've been looking since the later
'70's.

Cheers, gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Men will always be men -- no matter where they are.
-- Harry Mudd, "Mudd's Women", stardate 1329.8

 

[Thorsten Kampe]

* Thomas 'PointedEars' Lahn (Sun, 17 Jul 2011 14:35:15 +0200)

You might want to check your English dictionary. Indenting is commonly
understood in typography as "To begin (a line or lines) at a greater or less
distance from the margin"¹. In particular, in computer programming it
usually means that there is, at most, whitespace on the left of the text.²
In that sense, the above is _not_ indentation (or indenting), as neither
"variable" nor "variable =" consist only of whitespace. It is only
aligning.³

*doublesigh* that is actually the point I was trying to make. From a
programmer's point of view the distinction is artificial because he does
essentially the same: press the tab key or the indent button to move the
stuff right from the cursor to the right so it gets aligned with the
stuff above.

Thorsten

 

[Thorsten Kampe]

* gene heskett (Sun, 17 Jul 2011 10:29:03 -0400)

When you find it Dotan, let me know, I've been looking since the later
'70's.

The "perfect programming font" is just the one that looks so good that
you would also use it for writing email. Dejavu Sans Mono is pretty
good. Consolas looks also looks good but it is Windows only.

Thorsten

 

[rantingrick]

This.  I used to think that tabs were better, for pretty much the
reasons Rick outlined, but I've had enough problems with editors
munging my tabs that I eventually found it simpler in practice to just
go with the flow and use spaces.

Solution: STOP USING BROKEN TOOLS!!!

Of course, there is also another major problem with tabs that I have
not seen pointed out yet, which is that it's not possible to strictly
adhere to 80-column lines with tabs.

Of course it is. The litmus test will be "four-space-tab-view". If the
code overflows in this "view type" then the code will fail the 80 char
maximum limit. This argument is ridiculous anyhow. It is up to you how
to view the source. If you view it in 80 width tabs don't start
complaining later when one indention goes off the page. Would you view
the source with 50 point font? Jeez.

 I can write my code to 80
columns using 4-space tabs, but if somebody later tries to edit the
file using 8-space tabs, their lines will be too long.

THEIR LINES is the key words. A tab control is a tab control is a (you
guessed it!) a tab control. No matter how small or large your tab
settings are the source only reflects one tab control char per press
of the tab key. Heck, people are already (unwisely) using "8-space-
spaces" and i don't hear you making the same argument.

Rick's answer
to this might be to just mandate that everybody uses 4-space tabs, but
then this would pretty much defeat the purpose of using tabs in the
first place.

We already mandate four space spaces so what is the difference? I'll
tell you, the difference is Freedom and Unity living in perfect
harmony.

Yes, we mandate that all code must meet the 80 line limit in "four-
space-tab-view", and if it doesn't, it's not allowed in the stdlib.
Plain and simple.

 

[Corey Richardson]

Excerpts from Thorsten Kampe's message of Sun Jul 17 11:10:57 -0400 2011:

The "perfect programming font" is just the one that looks so good that
you would also use it for writing email. Dejavu Sans Mono is pretty
good. Consolas looks also looks good but it is Windows only.

I use inconsolata, but I hate the look of it un-bold at small sizes, so
I keep it bold all the time. I've started using DejaVu very recently because
of that, it looks better on screen at small sizes (pixelsize=9 in my
~/.Xdefaults, as opposed to the 12 and bold with inconsolata). Inconsolata
looks great on paper, though. DejaVu Sans Mono isn't the prettiest thing
but it certainly gets the job done.
--
Corey Richardson
"Those who deny freedom to others, deserve it not for themselves"
-- Abraham Lincoln

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iQEcBAEBCAAGBQJOIw2kAAoJEAFAbo/KNFvpVU4H/2ASHNffuuupRYd4UOypNm7D
gRNv7kNKOeZREJdDWFbKkzMCzw0lJlon+nQ4elnz+3mdvIN0QftNPitiCdTXUykI
tDfj3eKnQJVeE2ELBbVmhlBRBM+7er7iPnySu8Z7f04zu3Fa+2wbLvvyyZN9UraC
Cv3bsQayDF8bL9sddnd37/e2q00RntKF9MTRkGKR4VQuIxnNf3Q0h2gd1J1CEQqT
MIlCd0QuQsFzlbUqmcSviVAmpFlBMGDHKWb1nBF5374CJ6qRHqP3D14ib+fv9A6W
ZR0gwpd0hvGbJou3b+ZggRTAsBWSE8nndYv3wD0KTBwmdz5Ty/GZ0FL16H2Hqx0=
=In7J
-----END PGP SIGNATURE-----

 

[rantingrick]

* rantingrick (Sat, 16 Jul 2011 09:51:02 -0700 (PDT))



Why are you so obsessed with indentation length? Indentation length is
just /one/ of the formatting choices that the author makes for the
reader - and probably the /least/ significant one.

I am not OBSESSED with it, i am just PERTURBED that we are not using
tabs; since tabs offer freedom to view the source at ANY indentation
level you choose REGARDLESS of what the author "thought" was
appropriate. It is a wise choice to only allow tabs in a language that
has FORCED indention. This is one way we can actually promote freedom
whist maintaining unity.

There is for instance maximum line length,

I like to keep lines at 80. Sometimes i go over if the code is not
something you would need to read often. If the code was to go into the
stdlib i would make sure it was 110% style guide compliant.

the number of empty lines,

I hate vertical white-space. I follow Python style guide suggestions,
and then some! I hate when people insert spaces into code blocks and
function/method bodies. If you feel a space must be inserted then that
is a good clue you should be using a comment there instead. Vertical
breaks should only happen before and after classes, methods,
functions, groups of GLOBALS, groups of import statements. Think of
func/method bodies as paragraphs and classes as sections of a book.
Two vertical spaces between classes and one vertical space between
func/methods.

the author's method of alignment, spaces between the equals sign and so
on.

I believe non-compliant spacing in args should throw an syntax error.
I hate this:

It should be...

Much easier to read when formatted into logical groups.

These are all much more "dominant" in the source code and none of
this is left for the reader's disposition.

It should be MANDATED. And these @holes who refuse to format their
code in a community standard will suffer the plague of syntax errors.
Who do these people think they are? Do they believe the rules do not
apply to them? I'll tell you who they are, they are F'ING format
criminals.

Compare for instance

variable        = 11
anothervariable = 22

def whatever (prettylong     = 1,
              alsoprettylong = 22,
              anotherone     = 33):
    pass

to

variable=11
anothervariable=22
def whatever (prettylong=1, alsoprettylong=22, anotherone=33):
    pass

Both examples show non-compliance to the Python style guide.Except for
this...

------------------
FUNCTIONS/METHODS
------------------
def whatever(
prettylong=1,
alsoprettylong=22,
anotherone=33):

OR

def whatever(prettylong=1, alsoprettylong=22,
anotherone=33):

I think the second is more readable for block openers. Note the
closing bracket and colon on last line!

------------------
CONTAINER TYPES
------------------

d = {
1:1,
2:2,
3:3,
4:4,
}

Note closing bracket on newline; and all alone! For hand stitching
containers you should put the "closer" on a newline that matches the
"opener's" indention level.

------------------
VARIABLES
------------------

variable = 11
anothervariable = 22

Stop trying to be an individual in a community. When you write code
for just you then write it any way you like. Go ahead and use that
Joker font and 10 space indention. Go ahead an use foolish spacing and
whatever. However when you are writing code in public or for the
stdlib you should always be Style Guide compliant.

You guys should feel lucky i am not the BDFL, because i would cast
plagues of exceptions on your lazy butts!

 

[rantingrick]

When I'm (consistently, of course) indenting code, I'm aligning it. When
I'm aligning code, I do this by indenting it, see for instance...

firstvariable = 11
variable      = 111

firstvariable = 22
variable =      222

The second "=" and the "222" is indented.

Or your example:
setup(
    name         = 'Elucidation',
    version      = '0.0.1-WIP',
    py_modules   = ['elucidation'],
    author       = 'Andrew Berg',
    author_email = '(e-mail address removed)',
    url          = '',
    platforms    = 'Windows',
    description  = 'Provides a class for storing information on
multimedia files that are to be converted or remuxed and methods to
convert and remux using popular tools.'

Why do you feel the need to layout your code in a "GUI-listview"
manner. Next you'll want column titles and column sorting... Jeez!
This is what you should have done...

DESC = """
Provides a class for storing information on
multimedia files that are to be converted
or remuxed and methods to convert and remux
using popular tools.
"""

setup(
name='Elucidation',
version='0.0.1-WIP',
py_modules=['elucidation'],
   author='Andrew Berg',
   author_email='(e-mail address removed)',
   url='',
   platforms='Windows',
   description=DESC,
)

 

[Chris Angelico]

You guys should feel lucky i am not the BDFL, because i would cast
plagues of exceptions on your lazy butts!

BDFL = Benevolent Dictator For Life. Note that first word.

ChrisA

 

[rantingrick]

Originally, tabs were a navigation device: When you press the tab key, you skip
ahead to the next tab column.  The notion that whitespace characters are
inserted into the text would have been very alien to someone using text
processing software anno 1970.  Same thing with space and enter; on typewriters
the space bar doesn't "type" anything onto the paper, it moves to the next
column, and that thinking carried over to computers.

And how much longer are we going to live in the past? Who cares about
backward compatible tabs. Mandate the four space tab now! Mandate that
Python takes four space and four space only! We shall lead the charge
for universal tab unity in all programming languages.

How long are you going to accept this multiplicity? It's ridiculous.

The reason the tab stop is a full 8 positions: for faster navigation.  If it
were 3 positions, it would take forever to skip from the start of line tocolumn
60.  You'd appreciate that, if you were e.g. writing a fiduciary reportwith
some text to the left and two number columns to the right, back in the day
before spreadsheets and word processor tables.

Just in case you were not aware this the year 2011. Spreadsheets have
been around for a LONG time. Stop living the past.

 

[Chris Angelico]

[a whole lot of guff]

Rick, you need to:

1) Grab the Python source code
2) Make your own version of Python that works the way you want it
3) Call it something different
4) Start your own mailing list.

Put your money - or, in this case, development time - where your big
ranting mouth is. Prove that your ideas are worth something by acting
on them.

Chris Angelico