Is naming variables after their type a bad practice?

Question

I\'m programming C++ using the underscore naming style (as opposed to camel case) which is also used by the STL and boost. However, since both types and variables/functions are

Answer 1

Personally, I capitalise my class names.

I disagree with, "it is unwise to choose names that differ only by capitalization", in this specific case. It's unwise to choose names which are confusingly similar. PoSItIoN and PoSiTIoN are confusingly similar. Position and position are not. Just make sure that when you search the code, you know and can control whether you're doing so case-sensitive or insensitive.

In cases where I have a function that only uses one variable of a particular type, then I might well name it after the type, since in English if something was, "the only position we're talking about", we'd refer to it as, "the position". Hence the variable name could reasonably be position.

Failing that, in your examples I might go with:

position pos;  // pretty sure people will realise I don't mean "positron".

mouse_over(entity target) // Returns true if the mouse is over the entity

manager &fmanager; // A reference to the framework's manager

devices::audio audio; // The audio subsystem
audio self; // "this" audio subsystem
audio audio_out; // The audio subsystem I'm configured to use for output

The last example is supposed to indicate that these problems might be solved by namespaces - outside the namespace in which audio is defined, you can safely refer to it as audio. Inside that namespace, functions operating on the audio subsystem frequently either are parts of the audio class interface which just happen to be free functions (in which case use conventions like self, other, lhs, rhs), or else are some kind of layered device or system which have an audio subsystem as a dependency (in which case, dependency for what purpose?).

entity and manager are terrible names for classes, by the way, since neither of them tells you anything about what the class represents. Every discrete thing is an "entity", and while not everything manages something else, "manage" is hopelessly vague.

Answer 2

This is why I picked up the old MFC practice of prefixing member variables with m_, as in "m_position." A lot of the Java people would do "thePosition" for essentially the same reason, though if you pointed out the similarity at the time they'd turn funny colors and rant at you.

Answer 3

Naming variables after their type specifically is indeed a bad practice. The code is supposed to be as type-independent as possible. That implies that any references to actual types should be restricted to declarations (again, as much as possible). Trying to embed type information into variable name would violate that principle. Don't do it.

What one might want to embed into variable name is the variable's semantical meaning. Like "width", "length", "index", "coordinate", "rectangle", "color", "string", "converter" and so on. Unfortunately, many people, when they see it, incorrectly assume that these portions of the names are intended to describe the type of the variable. This misunderstanding often makes them to engage into that bad practice (of naming variables after their types) later in their code.

A classic well-known example of such misunderstanding is so called Hungarian notation. Hungarian notation implies prefixing variable names with special unified prefixes that describe the semantic of the variable. In this original form Hungarian notation is an extremely useful good naming convention. However, in many practical cases it gets distorted into something completely different: prefixing the variable names with something that describes their type. The latter is certainly not a good idea.

Answer 4

Short and semi-wrong answer: If you have enough variables that you're working with in one place that you need non-cryptic variable names, maybe you have too many variables.

Though I actually disagree with that, to some extent. I think it has a grain of truth, but only that.

Some short variable names in C++ are just traditional and people know what they mean because they've been programming in C/C++ for awhile. Using i for an index variable is an example.

I think variable names should be named for their purpose. What's the position the position of? What's the manager managing? Why does this particular instance of the audio subsystem need to exist?

The trailing _ notation is used to distinguish member variable names. It can be very helpful when someone starts mentioning x out of nowhere to see x_ and know that it's coming from the class, and isn't declared in an enclosing scope or the global scope.

Answer 5

I have the same "problem" on a regular basis. I think it's a problem of abstration: In case of Position I'd suggest to abstract a bit more and introduce a type Point or something like that. Or specify what position is ment:

position mouse_pointer_pos;

Answer 6

Giving a variable the same name as its type is almost always a bad idea, because it makes it very difficult to tell what code refers to the type and what code refers to the variable. For example, consider the following class:

struct position
{
    void operator()() { }
};

// later on, somewhere:
position position;

Now, if we see a line of code that uses:

position()

we can't readily tell whether that constructs a position object or calls position::operator()(). We have to go back and see whether there is an object named position currently in scope.

Naming conventions are a very touchy, subjective, and argumentative thing. I would just recommend picking one that distinguishes types from variables in some way. Personally, I choose to capitalize my types and leave my variables as starting with a lowercase letter.

It doesn't really matter how you distinguish them (your suggestions of using capitalization or a trailing underscore are both common), just so long as your usage is consistent.