How do you reconcile common C++ naming conventions

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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