Re: [boost] Suggested coding guidelines

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-07-03 12:56:53

----- Original Message -----
From: "Don Waugaman" <dpw_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, July 03, 2001 1:50 PM
Subject: Re: [boost] Suggested coding guidelines

> > I think a strong convention is actually harmful, because it will
encourage
> > users to rely on it.
>
> That's true, but there are two ways of looking at it.
>
> 1 - Users rely on it for external include guards, which I agree we should
>     discourage.
>
> 2 - Library maintainers or those using the library rely on it as a
reminder
>     of the filename they're working on.  Perhaps it's not vital, but I'd
>     hate to do without the mnemonic in one sense or the other.

The filename is almost certainly more reliably visible elsewhere (e.g. the
window title of the editor). The #include guard is not on the screen unless
you're at the top of the file.

Anyway, I intend that the filename is part of the guard symbol, so what's
the problem?

> One possibility would be to bump the guid with every release of Boost.
> Writing a script to append guids to the header files shouldn't be too
> hard - or, alternately, to change guids that are already there.
> Users still couldn't rely on the actual include guard name, but the
> convention would still hold for maintainers or onlookers.

Mindless busywork for Beman when we release. Even GUIDs are too much
trouble.

> > 2. It should not take me more than about 2 seconds to come up with the
> > #include guard for a new header.
>
> Bumping guids with every release should take about two seconds for all the
> boost headers :-), with sufficient automation.

Overkill. What's the point?

> > The guideline as written does that. Someone will have to come up with a
> > pretty compelling argument to get me to change it. Actually, if the
group as
> > a whole had a strong preference for something else, and could agree on
what
> > that was, I would consider changing it, even if the group couldn't
justify
> > the decision. If y'all want to discuss this and come up with a consensus
> > counterproposal, go for it. I will sit out and wait for the outcome.
>
> I'd be happy with the guideline as written, but think that strengthening
> it could help.

With what?

-Dave