Re: [boost] Re: Tabs creep back into source files

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

>From: "David B. Held" <dheld_at_[hidden]>

> >"Eric Woodruff" <Eric.Woodruff_at_[hidden]> wrote in message
> >news:025801c25825$b1f7b370$1800000a_at_soy...
> >
> > Spaces are lowlevel, tabs are highlevel.
>
> And if Boost used a high level document format like PDF or RTF, that might
> be a consideration.
>
> > There just needs to be a standard of 1 tab per indentation, not two. If
> > you like your indentation to be further, use a wider tab. It is no
> different
> > then specifying 3 spaces for indendation vs 4 or 8. The unit of
> indentation
> > is all that needs to be consistent, not the method of implementing it.
>
> You also have to forbid leading spaces after tabs (for instance, to indent
> a partial tab...6 spaces, on a 4-space tab).

No, that's ok, as long as the space is used for alignment, not to denote
indentation level.

> And what is the benefit of
> using tabs for indents, but spaces for alignment?  I like to align member
> function names in my classes at a certain column, even if there is text
> before it (like a return type).  Using a different tab size is going to
mess
> up the alignment of my code (because c'tors don't have a return type to
> align).  Here's what I mean:
>
> Tab size: 4
> Function indent: 16
> '*' == ' '
>
> class foo
> {
> ****************foo() { }
> ****void********bar() { }
> };
>
> Tab size: 2
>
> class foo
> {
> ********foo() { }
> **void********bar() { }
> };

Here's a solution ("*" = space):

class foo
{
<tab>*************foo() { }
<tab>void********bar() { }
};

Using this, the return type (if any) will be indented one level (if that's
what you meant in the code above), and the function names align nicely, no
matter what tab size you use.

> [Beman wrote:]
> > > "* Developer A of library has tabs set for 4.
> > >  * Developer B commits trivial fix. Developer B's editor had tabs set
at
> 2,
> > > but converted tabs on the changed line only to spaces.
>
> > If developer B uses tabs of 2, I can't possibly see how it is messed up.
>
> See above.
>
> > They purposely want their tabs at 2. "Messed up" is highly subjective.
>
> I don't think you'll find many people that think the second version of my
> code above is not "messed up".

Not anymore. :)

> > If the standard is to use tabs, then obviously, the standard must be
that
> the
> > tabs remain in the files, and editors that translate them are not
allowed.
>
> The problems, of course, are partial tab indents, tabs-for-alignment, and
> "assumed tab width indent", which is the problem illustrated above.  That
> is, my code assumes that the tab size is 4, and aligns other text (with
> spaces) accordingly.  One workaround is to use one indent, and add
> spaces to the rest of the line, but who really wants to maintain that
> convention?

I don't see any problem with that. It means that then, people get the
indentation size they want, rather than the size to whoever started on the
program.

Regards,

Terje