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

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

Answer 2

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

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.