C++ Feature Whitelist/Blacklist

[Patrick Williams]

On Mon, Nov 07, 2016 at 02:25:30AM -0800, Nancy Yuen wrote:
> > Back to Big Picture
> > ----------------------------
> >
> > I do feel we are seriously missing a broader philosophical question.  In
> > what ways do you feel the CppCoreGuidelines do not address all of your
> > coding guidelines suggestions?  Rather than write an entirely new
> > document why would we not simply point to that and then extend it if we
> > feel it is insufficient in a few key areas.  As you saw in my previous
> > email, nearly everything we agree on comes from the CCG already and
> > nearly everything we disagree on is a contradiction from the CCG.
> 
> Our intention isn't to come up with a new document.  In our summit
> meetings, you agreed we could propose a coding guide as you didn't
> have anything spelled out and you didn't want to tackle it.  So we put
> together an initial proposal and we're discussing it.  If your decision is
> to say that CCG is the final say for all coding practices in openBMC
> then we'll have to figure out what that means for us.
> 
> > I do not want to hear that the CCG is "too long".  If you take out the
> > references it is in the same order of magnitude as the GSG.  It is also
> > organized in a way where each section is a straight-forward statement to
> > be followed, so anyone unfamiliar or uninterested can simply read the
> > TOC to understand all of the rules (ex. "I.2 Avoid global variables.",
> > E.6 Use RAII to prevent leaks").
> 
> "You do not want to hear"...I don't understand why you state is in such
> a manner or assume we'd make this point.
> 
> > --
> > Patrick Williams
> 
> ----------
> Nancy

Nancy,

From my perspective, I've pointed to the CCG as the primary document
from the very beginning.  At the summit I recall hearing two arguments
against it (and it could very well be my misremembering):

    1.  It is insufficient.
    2.  It is too long.  (I remember specifically 'reams of paper' being
        thrown about).

It is really hard for me to refute your team's perspective of it being
insufficient without examples.  You did point out the 'iostreams'
direction in our discussions and I also freely admit both CCG and our
current 'guidelines' are lacking in what is classically called 'style'
(indentation, naming conventions, etc.).

I was also unable to on the spot refute the "it is too long".  It is
easy to assume that the Google Style Guide is shorter, but after this
discussion began I checked the two to compare and came to the conclusion
they are in the same ballpark.

I assumed, perhaps incorrectly, that your team in taking up the "style
guide" would focus on #1 (where you feel it is insufficient).  It is
very frustrating to see the proposal simply be a rephrasing of the most
contentious points of the GSG, because it contradicts the CCG in these
areas.

I would like to call a "reset" to this discussion.  It is much easier to
critique a formal proposal than a supposed proposal.  I have therefore
spent this morning writing my initial take at a style guide.  I have
attempted to incorporate all of the areas your team (and a few non-vocal
members of our team) have expressed where the current guidelines are
incomplete, without violating or changing any of the current guidelines.
I do still treat the CCG as the "gold standard" here and have very few
exceptions to it recorded.  I have kept this proposal exclusively to
items that are not covered by the CCG.

Please have your team review this proposal for any areas that you feel
it is lacking in specificity.

    https://gerrit.openbmc-project.xyz/1024

These guidelines are also not "set in stone" and I am willing to deviate
from the CCG if we have good rationale and can come to a consensus as a
project.  I would like to see us first "approve roughly what is the
current mode of operations" and then subsequently "propose any
deviations".  I think each deviation should be approved on its own
merits and not as a hindrance on the document as a whole.

Is this acceptable?

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20161107/ef53a0ea/attachment.sig>