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