C++ Feature Whitelist/Blacklist

[Brendan Higgins]

>
> Hi Brendan
>
> First let me say thanks for your work formalizing processes and
> facilitating community
> participation by raising concerns, documenting things, your code
> contributions, etc.
> Thats all goodness.
>
> I think the lists below make sense 95% of the time.  Perhaps more.  If we
> have a formalized
> list such as the one below, and I find myself in the 5% situation, what
> does that mean?
>
> Maybe a better question for discussion is, could you elaborate on what
> advantages a community
> project with a set of non-negotiable rules would have over a project
> without such a set?
>
> thx - brad
>

Great question,

First off, what I consider a blacklist to be: I call it a black list to
distinguish it from the rest of the style guide purely for the purpose of
discussion; I do not plan on submitting this as part of a separate
document; they will be mixed in with the rest of the style guide.
Nevertheless, most rules and suggestions in a style guide are much weaker
than effectively removing a feature from a language. Things are usually
discouraged, but not _forbidden_. Naturally, a stronger rule requires more
discussion and will elicit a stronger reaction from someone who either
agrees with it or disagrees with it; that is the only reason I pulled it
out into a separate discussion.

What I mean when I say forbidden: I think there are exceptions to every
rule, but if a style guide says something is forbidden, the person who is
writing the code needs to document clearly why he is breaking convention
and the reviewers are to make clear that the exception is well explained
(and that they agree with it). So  I would not say they are non-negotiable;
they place a clear onus on the people writing code to document a very good
reason for doing something which makes it easier for reviewers; it also
makes it easier for people writing code because they know what they are
allowed to do and what they are not; so they know what to expect when time
for code review, saving review cycles and thus time.

Cheers!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20161102/5132de90/attachment-0001.html>