Re: [boost] Suggested coding guidelines

From: Ed Brey (edbrey_at_[hidden])
Date: 2001-07-03 17:11:27

: "David Abrahams" <david.abrahams_at_[hidden]>
> >
> > 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.

I'll join you, especially since mangling for the sake of code management
in the face of restructuring may make moot the issue of reliability.
>
> > > 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?

"""
I don't ever do that intentionally. I learned long ago that bending the
rules here or there at a whim tends toward code rot. Eventually your
program
grows such that all of your acceptable violations become unacceptable.
This
happens insidiously, so they never get addressed.
"""

I thought that was well put.  (By first paragraph, I meant the first of
the two paragraphs that I was quoting.)

> "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.

My point was simply that I was initially confused/mislead by
"forbidden".  I really thought you meant something different than your
true intent (as I now understand it).  It's not a big deal because I
figured it out in the course of reading the remainder of the guidelines.
On later reflection, I'm not so sure my "abstain" suggestion is that
much better.  I liked the nuance of refraining _by one's own choice_ in
the definition, regarding the ability to deviate in special situations,
but the word convey any particular strength of the guideline.

I'm sure most readers will figure out what you mean in any case, so this
issue probably isn't worth worrying about.  I do still think it is
important to convey an idea of how closely the authors recommend to
follow the guidelines.  After all, the guidelines are all about giving
advice, and advice on how to apply the advice is valuable if it leads to
better programming decisions.