C++ Feature Whitelist/Blacklist

[Nancy Yuen]

My comments inline.

On Sun, Nov 6, 2016 at 7:44 PM, Patrick Williams <patrick at stwcx.xyz> wrote:
>
> Nancy,
>
> A few minor responses below.
>
> On Fri, Nov 04, 2016 at 02:46:42AM -0700, Nancy Yuen wrote:
> > As for fitting in the head of the contributor or maintainer, I don't
think
> > it's reasonable.  One of the points made during our meeting was that
> > openBMC should be a project other people can come in and contribute to.
> > Future contributors may or may not be devoting all their time to openBMC
> > and may not have the bandwidth to "fit" one of the repos in their head.
>
> What I meant by this was not that every contributor is expected to know
> all of the code, but that the maintainer is likely to know the internal
> APIs of it enough to be able to review contributions.  One of the main
> points of contention is a proposal that "makes it easier to review" and
> that is the part that makes more sense when you are talking about 1+
> MLOC of interdependent code.  That particular point is less interesting
> when you are talking about <50kLOC.
>
> > Btw, Google's codebase is not monolithic.
>
> I realize that was not likely the case, but those were the words Titus
> used in his public talk.
>
> > I also want to echo Brendan's caution in his reply with regard to citing
> > industry experts.  [3] is not a list of do and don't dos by industry
> > experts.  Their abstract clearly states "Please try to verify or
disprove
> > rules! In particular, we'd really like to have some of our rules backed
up
> > with measurements or better examples"
>
> I feel you have taken this one sentence very much out of context.

I disagree.

>
> The first paragraph of the abstract says:
>
>     The C++ Core Guidelines are a collaborative effort led by Bjarne
>     Stroustrup, much like the C++ language itself. They are the result of
>     many person-years of discussion and design across a number of
>     organizations. Their design encourages general applicability and broad
>     adoption but they can be freely copied and modified to meet your
>     organization's needs.
>
> They are actively encouraging others to use this list.  The also state

I did not suggest they were encouraging people not to use their guidelines.

> in the abstract:
>
>     The rules are designed to be supported by an analysis tool. Violations
>     of rules will be flagged with references (or links) to the relevant
>     rule. We do not expect you to memorize all the rules before trying to
>     write code.
>
> In fact, clang-tidy has a number of checks for these rules to encourage
> their use.

I would love it if we could install clang-tidy to enforce these rules on
openBMC's gerrit.

>
> The one sentence you quoted I read as "We are willing to change these
> rules if evidence points to the contrary.  Please prove us wrong."  And,
> in fact, the guidelines are "actively maintained" on Github and have
> changed since their original introduction.

Actually, the sentence I quoted specifically mentions both verifying and
disproving their rules, not just disproving.  To me that says the rules
aren't perfect, may be wrong, have unintended consequences, scenarios when
it doesn't work etc.  To me it says please feel free to check that rules
have the intended affect and not use them blindly.

>
> --
> Patrick Williams

----------
Nancy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20161107/a8fe845b/attachment.html>