Tab indentions on different platforms?

[Steven D'Aprano]

On Wed, 02 Jan 2008 15:17:54 +1100, Ben Finney wrote:

> Torsten Bronger <bronger at physik.rwth-aachen.de> 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