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

Yes, it is a bad practice. Variable names should be more specific if they have a long lifetime or important meaning (temporaries are ok). Remember that C++ is very strictly typed- you can't have a variable and not be very sure what it's type is. A variable Type type, for example, basically just means that it doesn't have a name.

Answer 2

You can just follow existing guidelines, e.g. Google's C++ style guide

It's good to be aware of naming being an important issue, but in my experience thinking too much about it is as harmful as not being aware of it.

I've experimented with Hungarian and didn't like it, most good programmers I know don't use it.

The main point I would make is it makes code less readable.

Answer 3

No, I do this on occasions and it does not cause problems in the Microsoft world. For example,

class compiler
{
    symbol_table symbol_table;
};

has never caused any confusion. By the way, I called my cat 'cat' and that hasn't caused confusion either.

Answer 4

The biggest problem with this naming convention imo is that it's unclear to the programmer whether an expression refers to a type or an object. A way to eliminate such ambiguity is by wrapping your code inside a namespace (as it should) and using explicit qualifications, even on internal usage:

namespace my_ns {

struct audio { ... };
struct string { ... };

// Internal function whose logic doesn't require explicit qualifications.
void do_something()
{
    // Use explicit qualification nevertheless.
    my_ns::audio audio;
    audio.play("impenetrable.sd2"); // okay

    my_ns::string string;
    string.size();          // okay
    // string{}.size();     // oof, tryna re-instantiate object? compilation error
    my_ns::string{}.size(); // okay, size of just created temporary string
}

}

This is much like the way you use standard types such as std::string. Since all user-defined types will be qualified with their namespace, there'll be no ambiguity between types and objects. The downside of this is, of course, more verbosity:

namespace my_ns {

struct audio {
    // Using explicit qualification; pretty verbose.
    void play(my_ns::string a1, my_ns::string a2, my_ns::string a3);

    // Without explicit qualification; saves 21 characters.
    void play(string a1, string a2, string a3);
};

}

Answer 5

The local meaning is rarely a good unique global description of the type:

cartesian_point_2d position;  // rectangular, not polar coordinates
mouse_over(ui_entity entity); // not a business layer entity
xyz_manager& manager;         // what's a manager without something to manage?
audio_system audio;