Re: [boost] code naming conventions

Subject: Re: [boost] code naming conventions
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2016-03-06 17:41:32

On 7/03/2016 08:38, Michael Marcin wrote:
> I've written a lot of code in the boost/standard library style. I've
> become increasingly annoyed at naming my variables when coding in
> this style.

While not necessarily completely in keeping with Boost style, these are 
my thoughts on it:

> // type takes the most natural name
> enum class format {

This is not the most natural name, because you've lost context.  It 
should be image_format or similar.  This incidentally fixes most of your 
other issues as well.

(It gets a bit more problematic if you make this a nested type of the 
"image" class, because then the natural name does become "format".  This 
is probably an argument to avoid doing that.)

>      rgba,
>      rgb,
>      float // enum value wants reserved name

How about "floating" instead?  It's usually not hard to come up with 
alternatives to keywords without using funky punctuation.

>      // getter wants the same name
>      format format() const noexcept
>      { return this->format; }
>
>      // setter wants the same name
>      void format( format format ) noexcept
>      // parameter wants the same name
>      { this->format = format; }

Methods should typically be verbs and types should be nouns, which 
usually lets you avoid this.  It's only problematic in cases like this 
where the noun and the verb are spelled identically.  However renaming 
the type as above gets you out of this hole as well.

>      // member variable wants the same name
>      format format;

Typically member fields (especially where private) ought to have a 
prefix/suffix.  I generally subscribe to the "m_" prefix school of 
thought for these.

Although it's not strictly necessary if you're following the explicit 
"this->" convention instead -- but while the compiler can readily 
distinguish between "this->format" member and "format" parameter inside 
a method, I don't like code like this as it's too error-prone for humans 
(both to read and to write).  This is another reason I prefer the style 
where the type is "image_format", the parameter is "format", and the 
member is "m_format" (without "this->", although you can keep that if 
you prefer).