C++ Feature Whitelist/Blacklist
Patrick Williams
patrick at stwcx.xyz
Mon Nov 7 14:44:25 AEDT 2016
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.
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
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.
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.
--
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20161106/cc5440ff/attachment.sig>
More information about the openbmc
mailing list