Introduce yet another C++ naming style

[Patrick Williams]

I was out for a while at the end of December and didn't get around to
replying to this.  I don't want it to seem like you're being ignored.

On Tue, Dec 20, 2016 at 05:11:12PM +0800, Mine wrote:
> Hi All,
> 
> This email is to introduce a naming style I used in previous project, which
> I think is elegant and makes the code more friendly to read.
> I just want to share this style for discussion and if you think it’s
> better, we may use this style in OpenBMC projects.

There are a lot of different C++ style guides available online.  There
was quite a lengthy discussion previously on this mailing list as to
style guides.  I'm not really interested in doing a wholesale
replacement of the style guide at this point.  Part of the intent behind
what is currently there is to make them as simple as possible and then
"improve" them later.  Incremental changes are certainly welcome at this
point.

>    Some one prefer underscores like _bus to resolve this issue, some other
>    may feel bus is just good.

I am certainly not opposed to an "enhancement" of the current style
guide in this area.  The current wording is:

    We generally abstain from any prefix or suffix on names.
    Variables should all be lowerCamelCase, including class members,
    with no underscores.

I think it is reasonable to allow an underscore on class members because
it is not an unusual practice.  I personally don't find it necessary
from a code-review / code-maint perspective, but the Google guide
prefers an underscore suffix on all members.  Some code in our
repositories has an underscore prefix.  We should come up with a
consistent rule and document it if we want to allow it.

>    3. We may want to define a object with the same name as class’s name,
>    such as:
> 
>    class foo {
>      ...
>    };//foo foo; // This does not compile
>    foo myFoo; // We'll have to use a different name

The current wording is:

    Types: Structs, classes, enums, and typed template parameters should
    all be in UpperCamelCase.

I'm not seeing your issue.

>    4. During reading the code, sometimes it’s hard to find if a variable is
>    a local varialbe, or the class’s member, or a constant, such as:
> 
>    class Host {
>     std::string somePath;
>    };
>    ...const char* constPath = "xxx";
>    Host::xxx(const char* anotherPath) {
>     std::string theThirdPath;
>     // In this function, how do we tell if xxxPath is a local variable
> or class's member?
>    }

Why does it matter?  You're talking about two different attributes: constness
and scope.

What makes 'constness' special enough to warrant an explicit style-guide
requirement to differentiate?  Where do we draw the line on which
attributes are special enough to encode?

Isn't your function too large if you cannot easily differentiate between
local scoped variables (or parameters) and member variables?  This can
also be solved with the _ suffix, but I'm not sure if we want to go to
the extent to say "all members must have _ suffix".

> The naming style I introduce will address all these “problems”.

(see above on wholesale replacement)

-- 
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/20170116/638b8dcc/attachment-0001.sig>