C++ Feature Whitelist/Blacklist

[Nancy Yuen]

----------
Nancy

On Mon, Nov 7, 2016 at 11:57 AM, Patrick Williams <patrick at stwcx.xyz> wrote:
>
> 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?
>

Thank you for putting this together.  Having this openBMC programming
guideline will be really helpful for my team, especially for new members.
I will follow up with my team later today to see if it meets their needs.

With respect to this proposal, and any other issues in general that arise,
as long as it meets our needs and doesn't prevent us from making forward
progress with our servers, we will try to work with it.


> --
> Patrick Williams
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20161109/85223337/attachment.html>