feeding the troll (was: Tabs -vs- Spaces: Tabs should have won.)

Tim Chase python.list at tim.thechases.com
Sat Jul 16 13:52:34 EDT 2011


On 07/16/2011 11:51 AM, rantingrick wrote:
> 1) Using only one indention token removes any chance of user error.

I'm not sure it "removes any chance of user error"...programmers 
are an awfully error-prone lot -- especially beginners.  Picking 
one or the other might help reduce friction when learning or 
shifting between projects (which PEP-8's 4-space guideline does), 
but editor peculiarities may differingly save files.

> 2) Tabs create unity in the source code base.

This could go either way...fortunately the code is already 
written and tested and appropriately handles both tabs and 
spaces.  A dictum one way or the other would break existing code 
on the shunned side.  I can't say this is a particularly 
convincing argument.

> 3) Tabs create freedom in the form of user controlled indention.
>
> Indention width should be a choice of the reader NOT the author. We
> should never "code in" indention width; but that is EXACTLY what we
> are doing with spaces! No, the reader should be able to choose the
> indention width without ANY formatting required or without any
> collateral damage to the source code. Tabs offer freedom, spaces offer
> oppression.

While I prefer tabs for exactly this solitary reason, the fact 
that it means agreeing with rantingrick is almost argument enough 
to start preferring spaces. :)

> 4) Tabs remove the need for complicated indention/detention tools.

I'm not sure this has ever impacted me.  It's always been a 
function of the editor, and using Vim, this is a non-issue for 
me. I've used several other editors as well and most worth any 
time-investment have options to control just this behavior 
(expanding tabs to spaces & how many spaces a tab should be 
treated as).  I flip back and forth between several projects, 
some use PEP-8's 4-space indentations, some use a single tab, and 
one uses an oddball 2-space indentation.  It's a single command 
in Vim to adjust for the projects, and the ones I work on most 
frequently are the ones I have set as my defaults.

> We should never create languages that cater to the selfish. Our rules
> must take in consideration the "good of the many", and NEVER "the good
> of the few".

so sayith the guy who selfishly wants to change existing 
standards of freedom-for-many to the preference of his few? :)

-tkc







More information about the Python-list mailing list