On Wed, 02 Jan 2008 15:17:54 +1100, Ben Finney wrote:
> Torsten Bronger <[EMAIL PROTECTED]> writes:
>
>> [...] the width of a tab is nowhere defined. It really is a matter of
>> the editor's settings.
>
> RFC 678 "Standard File Formats"
> <URL:http://www.ietf.org/rfc/rfc678.txt>:
Dated 19 December 1974.
I really recommend that anyone following this thread read the RFC. It
will give you a good mindset of how things were THIRTY YEARS AGO, before
Unicode, before extended ASCII character sets, before Postscript, before
laser printers, before graphical monitors, before you could choose your
display resolution and typeface.
Some recommendations from the RFC, with my comments in braces {}:
The end of line convention is the Telnet end of line
convention which is the sequence <CR><LF>.
{ anyone here like to predict what Ben, a Linux user, uses as his end of
line terminator? }
Format 1 [Basic Document]
This format is designed to be used for documents to be printed on
line printers, which normally have 66 lines to a physical page,
but often have forced top and bottom margins of 3 lines each.
Active Format Effectors
<FF>, <CR>, <LF>.
Page Length
60 lines.
Page Width
72 Characters.
{ who measures page width in characters any more? doesn't that depend on
how wide each character is? and lines per page? }
I think it tells a lot about the spaces-only argument that it is based on
the state of the art thirty years ago, when people's choice in displaying
and printing code was limited to one fixed width typeface per platform.
If you actually view the RFC in question, it demonstrates just how
obsolete it really is: fixed page breaks, hard coded page numbers, and
with a hard coded 72 characters per line, the page's text takes up just
over a third of my browser window, leaving 2/3rds blank. Printed is a
little better: only 1/3rd of the printed page is left blank. Follow this
RFC, and you too can needlessly waste screen real estate and paper!
That's the world the spaces-only proponents still live in: everybody must
write to the lowest common denominator just in case some day, some where
some programmer might have to edit a source file by telnet on a fixed
width character terminal using ed.
If you are writing in an environment where it is likely, or even
conceivable, that this could happen, then of course you should set in
place an appropriate coding convention. That's the beauty of it: your
code base, you get to tell everybody who works on it what conventions to
follow.
But for the rest of us, needlessly writing to the technology of 1974 is
such a waste -- and I guarantee the 90% of programmers who aren't using a
Unix-based OS aren't doing the same. And without the limitations of the
72 character line printer, there is no advantage to using fixed spaces
for indents, and significant disadvantages.
> How many columns to indent source code is an orthogonal question to how
> wide an ASCII TAB (U+0009) should be rendered. The former question is
> open to matters of style; the latter at least is standardised, even
> given the caveats about enforcement.
The existence of an RFC that nobody pays any attention to is not a
standard.
>> If all Python code used tabs, eveybody could use their own preferences,
>> for both reading and writing code, and interoperability would be
>> maintained nevertheless.
>
> Interoperability isn't the only criterion though. On the contrary,
> source code is primarily for reading by programmers, and only
> incidentally for reading by the compiler.
Exactly, and allowing programmers to set their own indent width aids
readability. Forcing your choice on others works against readability.
It also hurts *editability*. Consider copying code from a source file
with 8-space indents into a source file with 4-space indents, or vice
versa. If you're lucky, your editor has a command to "clean spaces", or
otherwise re-indent, and it might even get it right. At worst, you have
to laboriously add or delete spaces by hand.
That problem simply does not exist if you use the rule one tab = one
indent level. You only need to re-indent when you are actually changing
the number of indent levels, not as a side-effect of different
conventions for the number of spaces per level.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
