Using tabs effectively. Was: Why not use tabs?

Joe Smith JoeSmith at bogusaddress.com
Wed Jan 19 04:58:00 EST 2000


If one is using all tabs, then putting a comment at the top of the file
indicating the tab setting seems like a waste.  If one is mixing tabs and
spaces, then it is needed.  Maybe the comment should be one of the following:
using all tabs, using all spaces or mixing with a tab setting of X.

It seems to me by using all tabs, one can change the indentation to suit their
needs.  For example, if I like two spaces, then setting the tab setting to two
gives me my preferred view of the code.  If you like 5, then you should be able
to set it to 5 and get your preferred view.  I think that mixing tabs and spaces
will normally cause problems.

The best solution is for your editor to know your preference and reformat the
text to your preference when it reads the file in (and it could write it back
out in the original format).  This would probably be difficult with python
because of the lack of an end of block indicator.  Since tools such as editors
are supposed to make our lives easier, you think that this would have been done
by now.


James Logajan wrote:

> Robert Meegan wrote:
> > Absolutely nothing is wrong with tabs, as long as you only use tabs.
> > The problem comes when people mix tabs and spaces, because it would
> > seem that every programmer on Earth uses a different default tab width
> > (I'm lucky, I got in when three spaces per tab was still available).
> >
> > Some people use eight-space tabs and type four spaces for an
> > indentation level so that their code has indentation:
> >
> > <-->
> > <- \t ->
> > <- \t -><-->
> > <- \t -><- \t ->
> >
> > etc.
> >
> > When you import this into your editor (set to three-space tabs, like
> > God intended) the effect is horrific.
>
> Under Solaris and Linux (and probably most other Unices) there exist the
> commands:
>
> expand
> unexpand
>
> Read their man pages. Note that they take an option about how wide tabs are
> to be interpreted. Also note that some versions (BSD?) of the "pr" command
> also have the "-e" option for setting tab width.
>
> The issue of "how many spaces to a tab" is an old enough problem *in all
> languages* that I'm surprised that it has never become a convention to put a
> comment at the top of all source files indicating what the tab settings for
> decent viewing should be. I've come across a lot of source code where tabs
> were intended to be every 4 characters to conclude this is a sizable number
> of authors. (I used to use 3 spaces/tab early in my career.) The fact that
> some languages like Python are sensitive to the issue detracts from them not
> a wit in my opinion.
>
> I humbly offer the following rules to a long and healthy editing experience:
>
> 1.0) If using tabs (regardless of tab setting):
>    1.1) Use nothing but tabs for indentation!
>         Do not mix tab and space indentation!
>    1.2) Indent at whole multiples of your tab settings lest you make it
>         impossible to conform to rule 1.1.
>    1.3) Place a comment at the top of your file indicating the tab
>         spacing. Even if using tab settings at 8.
>    1.4) Run the unexpand utility (if on Unix) on the file to minimize
>         the chance of accidentally violating rule 1.1.
> 2.0) If using spaces:
>    2.1) Use nothing but spaces for indentation!
>         Do not mix space and tab indentation!
>    2.2) Place a comment at the top of your file indicating that tabs
>         do not exist as indentation and should not exist.
>    2.3) Run the expand utility (if on Unix) on the file to insure
>         that you have not accidentally violated rule 2.1 and 2.2.
> 3.0) If trying to impose a particular tab setting as standard:
>    3.1) Try using a thimble to turn back the tide, as you will have better
>         luck at success at that than in imposing a specific tab spacing
>         as "correct".
>
> Rules to follow for extra credit:
> 4.0) For lines longer than 80 characters:
>    4.1) Keep all lines under 80 characters and manually insert line
>         breaks at reasonable points. Do not rely on automatic editor
>         line wraps.
>    4.2) If reasonably possible, (and it normally is) indent line
>         continuations to at least the same indentation level as the
>         continued line. (Much like the sentences in these paragraphs
>         have been "continued" at the same indentation level.)
>
> 5.) Don't expect any of these rules to be followed except this one.
>
> P.S. I sure hope Netscape Communicator didn't convert any of my spaces to
> tabs! ;)




More information about the Python-list mailing list