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).