A case against naming conventions based on type
Many places I have worked have naming conventions that are, in my opinion, poorly conceived. Naming conventions really should be limited to deciding between camel case, pascal case, and simply, “Give it a name that explains what it is supposed to be for.” Unfortunately a lot of places go much further and do things like putting ‘m_’ before member variables, having different naming conventions for different classes of entities (Pascal for classes, underscore for functions, camel for variables, _t after typedefs, etc…). These kinds of conventions miss the point of generic and object oriented programming and thus miss the point of C++ in a great way.
The issue is that what kind of thing an entity is doesn’t really matter so long as a certain interface is obeyed. Take for example putting the “_t” postfix on typedefs, which many developers and firms do. What happens now when someone comes along and decides that this type would be better implemented as a class of its own rather than a typedef of something else. Since typedefs in C++ are weak this is not a surprising or all to rare thing to do. Now in order to keep from breaking clients everywhere we need to follow the convention for naming classes and then add a typedef so that the “_t” name exists. This is silly.
Another example comes up with regard to functors. Functors are classes thats’ instances look and behave like functions that may have state. If you’ve specified that variables must be named one way, and functions another, then in fact you’ve got a problem here because conceptually this variable is both a variable and a function! If you replace a function with a functor someplace then again you are in the unfortunate position of having to violate naming conventions or do something silly like make a function to call the functor just so both names exist.
The C++ standard library has a pretty good C++ naming convention. It uses one convention for almost everything with the caveats that template parameters are named differently (and this is important because of dependent name issues) and so are macros. Both of these things require special consideration when using so it’s worthwhile to make them stand out.
In C++ types are strong at the time of compilation, but in the source they are interchangeable to a great degree. So long as something obeys an interface, calling code shouldn’t have to change when you completely change the type some entity is. Naming conventions that force you to change names based on type hinder this ideal.