Re: [boost] Suggested coding guidelines

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-07-03 17:47:51

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

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

Okay. I don't think the restructuring argument is a strong one (it happens
rarely, and even so there's no reason that guards need to be updated), so I
would be open to a convention that uses the relative path to the file.
Others have made good arguments for its readability, it is easy to follow
and it is a "uniquifying" convention, so it meets my criteria for
acceptability. I would be open to that.

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

Done (in the discussion following section 2). See CVS.

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

Thanks. I added a section in the introduction for this. See CVS.

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

Okay, I am convinced. I hope my change described above helps.

-Dave