tabbing probs (was: Prothon Prototypes vs Python Classes)
mogmios at mlug.missouri.edu
Mon Mar 29 18:03:25 CEST 2004
>I think you misunderstood. There is no "standard" length of
>a tab. A tab is supposed to insert (or otherwise render the
>equivalent of inserting) enough spaces to go to the next "tab stop",
>which by convention is a multiple of 8 columns on a fixed
>width mechanical typewriter. This is where tabs originated.
No, I just fail to see why it matters. A tab could be 4 columns, 8
columns, 15 columns, or whatever on a particular editor and code blocks
will still line up.
>It matters. 8 columns is much too wide for indents in readable code.
>People do differ on that, but that seems to be the concensus.
So rather than switch editors or change your editors settings you'd
rather everyone be forced to use spaces? I presume four spaces? If
someone uses eight spaces to indent will that also break the code? It
seems to me that it'd be easier to configure an editor to show tabs as
four columns, if you so desire, than to configure an editor to show
eight spaces as four columns. Eight spaces is no easier to read than a
tab that takes eight columns. It's just more typing to correct the problem.
By my own preference, if I'm forced to use spaces to indent rather than
tabs, then I'll most likely use a single space to indent because I don't
want to deal with pressing the space and backspace keys multiple times
(trying to keep count) to make blocks line up correctly. I also don't
find it acceptable to use an editor which kludges together such space
using behavior for me to do what tabs would have done in the first
place. Overall, I think I find code that uses a single tab, rather than
a single space, to be easier to read.
More information about the Python-list