CStupidClassName

by Dejan Jelović

I'm seeing too many classes whose name starts with a capital 'C'. CMainWindow. CParameters. CSecurity. CThis. CThat. This madness must stop!

The first company that started doing this was Borland. They just added objects to their Turbo Pascal compiler, and wanted to ship a large class library.

Now, Borland's managers may be complete morons, but their engineers were quite good. They knew about barriers to entry. If they shipped this huge class library with generic names like Time and String, some of their clients would already have a record (record == C struct) named Time and String, and they would be unable to compile their stuff with the newest version of the compiler. And if you are a busy software engineer with a deadline close by, you won't spend your day troubleshooting the problems you have with your new compiler. You will simply dump it and revert to the old one.

The solution that Borland's engineers came up with is to prepend every class name with a capital 'T'. Thus we got TWindow, TTime, TString and such.

Borland, of course, expected everyone to continue using normal class names, without the capital 'T'. Or, in case of other library vendors, other capital letters. That would reduce the chance of collision to the two libraries using the same capital letter plus having the same class name.

However, programmers are busy people. They frequently take concepts provided by their vendors at face value. So when they saw that Borland was using a capital 'T' to name their classes, they thought that for some reason that is a good thing. Otherwise, the smart programmers at Borland wouldn't be doing it, right?

This of course defeated the whole system. Yes, Borland was able to ship their first version of the library without causing compilation errors in the existing code base, but as soon as the practice of using the capital 'T' spread, every new version of the library had the same problem.

So this adding of capital 'T's did no good in the long run.

Microsoft Joins the Fray

Next comes Microsoft. Since they only had a C compiler they were quickly loosing market share to Borland C++, and had to come up with a new C++ compiler and a class library. They have the same problem that Borland had few years ago: If they ship out a new C++ compiler and it won't compile the existing customers' C code, they are in trouble.

So what do they do? They add a capital 'C' to the name of each class they ship with their compiler.

Again, the users follow: They add a capital 'C' to the name of each class, and the system is defeated.

Thus we live in a world of classes with a capital 'C'.

What Should You Do?

The first common sense thing you should do is abandon the capital 'C' for your class names. Since everyone is using them, by not using them you are reducing the chance of a name conflict.

Second, learn about namespaces and start using them properly.

But isn't the Capital 'C' Useful to Distinguish Classes?

How is the difference between a class and a struct useful to a person using either? Can you name one situation in which this distinction would be useful, and not clutter?

There are only two distinctions useful in C++ code:

1. Whether a name is a data type or a function.

2. Whether a variable is a class-level variable or a function-level variable.

The first distinction is useful for looking at the code with parenthesis, i.e.:

something (2); // did the code just create a function or a temporary variable 

The second is useful in order to avoid using the wrong variable in a function.

So What Should I Use?

Use the simplest thing that works. For example, many of the people on the C++ standards committee use the following naming convention:

1. Data type names start with capital letters.

2. Variable and function names start with lower-case letters.

3. Class-level variables end in an underscore.

An example of this would be:

class MyClass {
public:
    MyClass (int numYears) {
        numYears_ = numYears;
    }

    void setYears (int numYears) {
        numYears_ = numYears;
    }

    int getYears () {
        return numYears_;
    }

private:
    int numYears_;
};

An alternative to rule #3 is to use the Microsoft convention of pre-pending class-level variable names with "m_". Thus the variable in the above example would not be numYears_, but m_numYears. Both are good and do the trick.

Feedback

Ae few days ago I got  message from Ernesto Guisado informing me that I was wrong to think that Borland was the first widely-known company to use the capital 'T'. Here's his e-mail:

From: Ernesto Guisado <erngui@acm.org>
To: "Dejan Jelovic" <djelovic@sezampro.yu>


Hi,

just read your article 
(http://www.jelovic.com/articles/stupid_naming.htm).

I agree with the ideas that you so nicely express in the 
article, but have to point out a factual mistake:

"The first company that started doing this was Borland"

See 

<http://developer.apple.com/tools/macapp/macapp_advantages.html>

for some history:

"Versions 1 and 2 of MacApp were written in Object 
Pascal. In the early '90s MacApp was ported to C++ and 
the result was Version 3.0."

MacApp is full of TApplication, TWindow, ...

This was in 1986.

Borlands OWL was created by the Whitewater group, who 
also created the Actor language. Actor is a kind of a 
Smalltalk with Pascal/C syntax, so there might be the 
link to the TFoo thing.

See also:

<http://www.applefritter.com/lisa/texts/Lisa_ToolKit_3_0_Sources.pdf>

This was for the Apple Lisa (programed in Clascal), and 
it already used TByte, TOctet,...

This "Apple Lisa Toolkit 3.0 Source Code Listing" 
(29/1012) has a very interesting line:

TByte = -128..127; {The T-names are so programs can 
USE UObject, NOT USE UClascal, and use "Byte"}

This might be a confirmation of your theory!

Regards,
Ernesto.

Read more...


From : http://www.jelovic.com/articles/stupid_naming.htm