Boost logo

Boost :

From: Eric Woodruff (Eric.Woodruff_at_[hidden])
Date: 2002-09-09 18:34:07

Yes, I know people do crazy things with their alignment and they think it
provides significant value. In reality, you should never have deeply nested
blocks, and blocks should be at THE MOST 20 lines, all of this alignment is
moot when most methods are at the 10-15 line level.

When one writes highly maintainable code, it doesn't even matter if it is
using a fixed width font, it's a non-issue. I used to like to code in
Palatino Linotype. (Take the examples in The C++ Programming Language for
example, they are not in a fixed width font and it is unnecessary the are no
behemoth switch statements)

I will certainly agree with someone that points out that boost has to
sacrifice maintainability for functionality, and the macros and large
numbers of template specializations just come with the territory. And once
boost is done, it's done, there's limited maintenance except for redesign or
supporting a wider range of platforms.

Again, people do strange things with alignment, and yes, spaces can support
them all, just like tabs. If spaces are more "portable" then so be it.

Your desired spacing method is hideous.

Note: A good editor would force the indentation automatically in a block,
and never let it be violated. The purpose of the tabbed indentation is to
show the scope, especially since it matters so much in C++.

----- Original Message -----
From: David B. Held
Newsgroups: gmane.comp.lib.boost.devel
Sent: Monday, 2002:September:09 15:21
Subject: Re: Tabs creep back into source files

>"Eric Woodruff" <Eric.Woodruff_at_[hidden]> wrote in message
> 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
> then specifying 3 spaces for indendation vs 4 or 8. The unit of
> 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). 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() { }

[Beman wrote:]
> > "* Developer A of library has tabs set for 4.
> > * Developer B commits trivial fix. Developer B's editor had tabs set at
> > 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".

> If the standard is to use tabs, then obviously, the standard must be that
> 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


Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at