How do you reconcile common C++ naming conventions with those of the libraries

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?

Solution 1:

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:

https://google.github.io/styleguide/cppguide.html#Naming

Solution 2:

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.