Re: [boost] Tabs creep back into source files

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2002-09-09 17:20:54

>From: "Rob Stewart" <stewart_at_[hidden]>

> From: =?Windows-1252?Q?Terje_Sletteb=F8?= <tslettebo_at_[hidden]>
> > > Different people use different toolsets.  Some editors are more
powerful
> > than
> > > others, of course, and that's always a factor.  However, when I print
a
> > file, it
> > > goes from some command line tool, if I choose, to the printer.  It
doesn't
> > go
> > > through my editor.  (I'm primarily on Solaris at work.)  I could
probably
> > find a
> > > tool that would convert tabs to spaces according to some rule, through
> > which I
> > > could process Boost files, so I could get appropriate printed output.
> > However,
> > > even if there was a standard for indentation at Boost, other libraries
> > doing the
> > > same thing might have a different rule for mapping tabs to spaces.
> >
> > How could that be? If you use tabs for indentation, only, not for
alignment,
> > then they can always be reliably converted to spaces: 1 tab = N spaces,
> > where N is selectable by you. It could be hard to get the printer to
> > interpret tabs as a specified number of spaces, though, so you might
need to
> > run it through a tool to get the right spacing, yes. It may well come
out
> > right without it, but then it would use the printer's tab size, not
your.
>
> Consider if you use N=4 and have a line well indented.  Suppose
> that line uses 8 tab stops worth of indent.  That translates to
> 32 columns onscreen, right?  Now consider a program that
> considers a tab to be worth 8 columns (N=8).  That same number of
> tab stops worth of indent means 64 columns.  Now consider if that
> line has just 20 characters worth of text after the indentation.
> With N=8, the text exceeds 80 columns and wraps or is truncated.
> With N=4, the text is well within 80 columns.

Your point being what? The point was to use a program where you can _select_
the tab size (how many spaces a tab expands to). This was regarding
conversion to/from spaces (e.g. for printing). I can't understand what you
write here should be a problem.

In fact, what you write here is an advantage. If someone uses long lines,
you might shorten it, by selecting smaller tab size. That's something you
can't do with spaces.

> > > If there is
> > > no standard, but each library author is free to choose his/her own
rule,
> > then
> > > things get even harder.  For these reasons, using tabs for indentation
is
> > a lousy practice.
> >
> > Given the above, I don't find this a convincing argument. I can't see
any
> > other sensible way of converting tabs to spaces, than simple
substitution
> > for N spaces. I understand more Dave's reason that it may be hard, or
> > impossible, to ensure consistent use.
>
> If your editor did the translation when saving the file, then
> everyone will see the same indentation as you.  If your editor
> can translate multiple spaces back into tabs for purposes of
> giving the tab character behavior you like, then you're in the
> best of both worlds.  If your editor doesn't replace tabs with
> spaces when writing a file, then others will encounter the
> problems I've described.

The conversion back and forth between spaces will in all likelyhood not
work, as pointed out by Dave Abrahams. You need to separate between tabs for
indentation, and possibly spaces for alignment, or any alignment will get
messed up in the conversion.

Thus, for it to work, the files have to be stored as they are, with tabs and
spaces, so that others can choose their tab size, when loading them.

What problems you described? What you said in the previous section wouldn't
be a problem if the tool converting for e.g. a printer is able to be
configured for your chosen tab size, or any size that fits it, so that it
prints correctly.

Was that it?

> > > Your contention that tabs are some form of markup is only useful if
the
> > tabs are
> > > visible.  If they aren't visible, then the whitespace viewed in an
editor
> > or on
> > > the printed page is indistinguishable and there is no markup.
> >
> > Yes, you can't see them, but you notice them, when the cursor jumps. :)
>
> Frankly, I find that frustrating when editing code because I can
> never know when the cursor will jump and when it won't.  Still, I
> can understand you being accustomed to that behavior.

For me it's not a problem, as if tabs are used, I expect them to be at the
beginning of the line, and then it only makes it faster to move between
indentation levels. Although the ability to jump to the first non-blank
character, and auto-indentation I guess may make up for this, no matter what
you use. It may also make it easier to align correctly, as it may be easier
to see if you're on the right column, when the steps are bigger than 1.

Still, like you, I understand this is a matter of preference, as well. If
you don't like the behaviour, there's often an option to "cursor through
tabs", as well, making them appear as spaces, so that should take care of
that concern.

I'm used to either. When working on Boost code, I use spaces. When working
on my own, I changed to spaces a while ago, for the same reason, the
possibility to share it with others. However, with what I've learned
recently, I've converted my code back to tabs and spaces. As I'm the only
one working on it, the issues that have been mentioned regarding this
doesn't apply.

> > Anyway, that part was just a comment. The main point was that with tabs,
you
> > can select the tab size you prefer. People have widely varying
preferences.
> > Anyway, I can adapt to it just fine. Just like with other preferences,
you
> > can get used to more or less anything.
>
> I hope I've shown that there is more to this than you previously
> recognized and I'm glad you're willing to bend.

Uh. This is not about bending. I never said I disagreed with the Boost
policy in the first place. I had not made up my mind in the issue, as
without knowing the rationale, it wouldn't make much sense in agreeing or
disagreeing. :) I asked for the reason for it, and I got it. The reasons
given seems reasonable to me.

So this is not a matter of me changing opinion in this. It was a request for
the rationale.

I hope _I_ have shown that this wasn't a matter of changing someone's
opinion, then, your or mine.

It's a good thing that intendation and brace placement is not part of the
policy, when just tabs appears to be a quite hot topic. :)

Regards,

Terje