Re: [boost] Suggested coding guidelines

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-07-03 15:59:03

----- Original Message -----
From: "Ed Brey" <edbrey_at_[hidden]>

> Yes, if in the final tally, the number of error with mangling is
> approximately equal to number of errors without mangling, then the
> mangling isn't worth it.  (Note that this does not preclude mangling
> being useful for other reasons, such as reducing maintenenace during
> restructuring.)

You measure the probability of all colliding macros, but you could just as
easily measure the probability of all colliding names (in which case
namespaces are a waste of time, because the probability of colliding macros
overwhelms them?) or of all coding errors (in which case almost any
guideline is a waste of time, because most code has errors in it) or of just
colliding #include guards (which justifies my guideline). If an error is
easily avoidable, it's worth avoiding, IMO.

> > I don't want to have that argument. It seems entirely too pedantic.
>
> Iroincally, the point of the argument is that the mangling itself is
> pedantic, since it involves effort and rules with little tangible
> result.

I guess I don't agree with the way you measure benefit. IMO, we are not
going to convince one another, so, with respect, I withdraw from this
debate.

> > It also is easier than remembering exactly which contexts you're
> allowed to
> > use names starting with underscores. A simple rule, if not overly
> > restrictive, is more powerful than a complicated one.
>
> True.  But it is also easier to read (for me) _member than m_member in
> code, and there is a tradeoff.  I think the documents selection of
> forbidding the leading underscore and calling for m_ is fine, but as
> with any tradeoff, it is very valuable to include the thinking behind
> it, so it is easier to determine when, if ever, a different choice
> becomes in order.

OK, I will add more rationale.

> True.  About all you can say is what you mentioned in your warning in
> the first paragraph.

What warning?

> > They're common English words; you can check the dictionary. The coding
> > standard means what it says.
>
> That "forbid" is a common English word is exactly why I raised the
> point.  To me "forbid" means "never", which left be confused for a while
> as I was reading the guidelines until I pieced together a deduction of
> the authors' intent.  I don't connote any sense of exceptionalism with
> the word.  As such, the out-of-the-box meaning of forbid doesn't fit
> well with the guidelines intent, which is "don't do this without a
> demonstratable need".

Once again, the guideline really means what it says. However, I can't
control whether people follow the guideline.

> > If you want to write a preamble that describes "forbidden" and "avoid"
> and
> > everything else, by all means, do so. I doubt it would strengthen the
> > document; in fact I think it would weaken it. Maybe others will feel
> > differently.
>
> Maybe a better approach is to use a word that conveys the intent
> out-of-the-box.  Personally, I think "abstain" would do the job.  So
> depending on how uncommon are situations where the rule should be
> broken, the guidelines can say to abstain from x or avoid y.

"Forbidden" conveys the intended meaning, but I could change it to "abstain"
for the purposes of boost (where nobody, at least so far, intends to mandate
compliance). If the group feels a change of this nature would be a good one,
I'd like to take suggestions for alternative words also.

-Dave