Most C++ naming conventions dictate the use of camelCaseIdentifiers
: names that start with an uppercase letter for classes (Person
, Booking
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.
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.
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.
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