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?
The first character of the name should be a letter and all characters (except the period) should be lower-case letters and numbers. The base name should be eight or fewer characters and the suffix should be three or fewer characters (four, if you include the period).
Naming conventions are general rules applied when creating text scripts for software programming. They have many different purposes, such as adding clarity and uniformity to scripts, readability for third-party applications, and functionality in certain languages and applications.
Naming conventions make it easier for programmers to work with each other's code. They can also help developers understand their own code while writing complex programs over long periods of time. Effective naming conventions reduce the time wasted reinterpreting the same information multiple times.
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
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With