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.

About these ads

6 Responses to “A case against naming conventions based on type”

  1. I’m with you on avoiding naming conventions based on type, with perhaps a acknowledgement that on some platforms things like interfaces names beginning with a capital ‘I’ is pretty benign.

    Your article doesn’t really address your concerns about scope, in particular ‘m_’ (or trailing ‘_’) etc. I’d be interested to read your thoughts on this in more detail.

    • I’m less sure about scope but lean toward the thought that it’s a bad idea for many of the same reasons. On the one hand, the thought of having to change client code because I’ve changed the scope of something is questionable…it’s also useful to know how far the alteration of a variable is going to reach. Personally I find it unnatural but I don’t think it’s as big a mistake as naming based on type and may actually have its uses.

    • I would argue though that if you can’t remember the variables in your classes while you work on them, they’re probably too large and if you need to signify which variables are global, you probably have too many of them.

  2. How do you percept difference between these two conventions:

    struct foo {
    typedef T value_type;
    T value;
    }

    and

    struct foo {
    typedef T value_t;
    T value;
    }

    I prefer the first one, but objectively, I can’t have a serious issues with the former either.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 26 other followers

%d bloggers like this: