How do you reconcile common C++ naming conventions

问题:

Most C++ naming conventions dictate the use of camelCaseIdentifiers: names that start with an uppercase letter for classes (Person, Booking) and names that start with a lowercase letter for fields and variables (getPrice(), isValid(), largestValue). These recommendations are completely at odds with the naming conventions of the C++ library, which involve lowercase names for classes (string, set, map, fstream) and names_joined_with_an_underscore for methods and fields (find_first_of, lower_bound, reverse_iterator, first_type). Further complicating the picture are operating system and C library functions, which involve compressed lowercase names in C and Unix and functions starting with an uppercase letter in Windows.

As a result my code is a mess, because some identifiers use the C++ library, C, or operating system naming convention, and others use the prescribed C++ convention. Writing classes or methods that wrap functionality of the library is painful, because one ends with different-style names for similar things.

So, how do you reconcile these disparate naming conventions?

回答1:

One way it to adopt the C++ naming_convention, this is what most code examples in the literature do nowadays.

I slowly see these conventions move into production code but it's a battle against MFC naming conventions that still prevail in many places.

Other style differences that fight against old standards are using trailing underscores rather than m_ to denote members.

回答2:

Diomidis, I share your pain and have spent a lot of time switching between different schemes over the years, trying to find something that works with the different libraries/frameworks that I use (MFC and/or STL/Boost). When working with a single framework, such as the STL, you can try and copy the naming convention it uses, but when you introduce a different framework, it easily falls apart.

In the end I have adopted a single style for all new code that I write (based on the Google C++ style guidelines) and I refactor older code to use this style when appropriate. You cannot reconcile the different naming conventions very easily, so don't waste time trying. Enforce a scheme for your team/dept./company and stick to it - but don't get hung up on how 'ugly' the code may look when using a mixture of schemes.

The Google C++ guidelines are pretty good IMHO - with some minor amendments. Check the guide out here:

http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml

回答3:

Why the need to reconcile? As long as the code compiles, and you can get work done, don't worry about it.

回答4:

I tend to be a perfectionist when it comes to code style, and this has always bothered me. I wish there were a universal standard, but there isn't. In my professional career, I have found that as long as the programmers on an individual project are consistent, that is the best you can hope for.

Ultimately, I think it comes down to knowing from which library a method, object, or function comes from. If you know that, then it becomes easy enough to remember which convention is used by that library, assuming the project doesn't include a lot of libraries. I have tried adapting my own code to match that of the libraries I use, but it is always a moving target and just frustrating in the end.

回答5:

Fav quote::

The best thing about standards is that there are so many to choose from!

My suggestion would be to take the library's convention that occurs in your company's code most often (probably the C++ library, which I believe boost sticks to as well), and make that your standard. Otherwise, you might as well not have one at all.

回答6:

In the projects I am working on I follow to code conventions for my project. When I call something other I use API of that library.

I also would add that wrapping of library is a bad idea (there are a lot of them in the code base I am working on) because it is usually done by the developer who solve his own problem and as a rule it is inappropriate for usage by all other developers. From the other side high quality wrapping is expensive.

回答7:

Well, since we can't change the way the standard libraries are implemented, I guess we'll have to live with it. As for reconciling - while writing some Win32 API stuff a while ago, I tried naming my own methods in PascalCasing as it's done in the API, but it just didn't feel right. So I went back to naming my methods in camelCase. I agree it's a mess, but the other option is to adapt your style to every new framework or library you use, and then there's the issue that you mention of having more than one library using different conventions in a single project. So my advice is - stick to what feels right for your own methods and classes. Or - when in corporate environment - stick to your company's best practices and guidelines.

回答8:

I seem to recall reading a long time ago that they choose to make the standard library different from the recommended coding convention on purpose, to avoid naming collisions. I can't find any reference that mentions that now, however. I remember reading that you shouldn't use leading lowercase letters in type names because they were reserved for the standard libraries. I assume something similar is going on with the use of underscores. I really don't see multiple naming conventions as a problem, since it clearly separates the standard code from code in your project. I always code stuff in my projects using capital camel case for types and lower camel case for methods/members. My current workplace uses capital camel case for methods in addition to types, which irks me greatly. But, they also like Hungarian warts, which even MS has disowned :P

回答9:

Honestly, I would just use the library as-is and stick to your own coding style. You could wrap it, but that seems like overkill.

回答10:

You should embrace the difference.

When people see the use of remove_copy_if, they will immediately know that this is an algorithm. This is actually a positive feature as algorithms come with certain guarantees (or lack of).

We also use the naming convention for our own custom algorithms.