The Old Joel on Software Forum: Part 4 (of 5) - Naming conventions for classes

Naming conventions for classes

I'm sl o w l y moving toward more of an OOP in programming.

One issue I've facing:

What naming convention do you use for a base class and derived classes?

So, if I have a class which inherits from a CommandButton, what might I call it ? CommandButtonChild?

And if I derive another class from CommandButtonChild? CommandButtonGrandChild?

The real Entrepreneur
Tuesday, February 24, 2004

Why do you need to express the inheritance in the name?

Wouldn't it better to express the functionality in the name?

Is it really relevant to a user of the class whether a derived class inherits from the CommandButton directly, or has some more complex relationship?

That said, if the specialized class is still fundamentally a CommandButton, then perhaps in that case, having CommandButton in the name is not a bad thing. But this conclusion follows from functionality/interface rather than inheritance.

e.g.
CommandButton
CommandButtonWithSuperFunkyGraphics

S. Tanna
Tuesday, February 24, 2004

I agree... you certainly would call things CommandButtonChild? What is that?

Maybe ImageButton is a subclass of CommandButton. ImageButton tells me that it's a button with an image on it.

Almost Anonymous
Tuesday, February 24, 2004

I usually add adjective prefixes when subclassing.

superclass = Button
subclass = RedButton
sub-subclass = AnimatedRedButton

runtime
Tuesday, February 24, 2004

Inheritance means IS-A, so often, but not always, the name of the derived class will include the name of the base class. See the above buttons example. I just try to make sure that the name describes the class.

Mike Swieton
Tuesday, February 24, 2004

Usually I name from the general to the specific. I also often come up with a mnuemonic for describing the base class

dbconnection

dbc_sqlserver
dbc_oracle
dbc_msaccess

instead of

dbconnection_sqlserver
dbconnection_oracle
(yada yada)

I picked up this nasty habit from working with the Zinc Application framework in the early 90's and it stuck.

I can also be lazy by collapsing out the underbar to name the instance I'm using.

ie dbc_oracle dbcoracle;

The underbar usage is probably the least of my sins. I'm pretty much garaunteed to burn in hell for my use of setLongJump in C++ (;) before exceptions were introduced....

mikester
Tuesday, February 24, 2004

Ouch... Hungarian notation for classes. You should add some access modifiers, too , like "i_dbc_sqlserver" for an internal class. <g>

If it were me, I'd just use "SqlConnection," "OracleConnection" and "AccessConnection." If someone can't figure out that these are database-related classes, they have bigger problems.

Robert Jacobson
Wednesday, February 25, 2004

>superclass = Button
>subclass = RedButton
>sub-subclass = AnimatedRedButton

Funny, I do it the other way around :-)

superclass = Button
subclass = ButtonRed
sub-subclass = ButtonRedAnimated

That way in a class browser they all appear together (assuming your class browser orders by name).

Wednesday, February 25, 2004

You should make additional namespaces if you have too many classes in one namespace. All your button variations might be in Buttons, and then ordering in the class browser wouldn't be an issue.

Chris Nahr
Wednesday, February 25, 2004

Do not attempt to indicate class hierarchy in your names. Your hierarchy shouldn't really be so extensive anyway. If you find you need to subclass more than three levels deep on your first version of a project you should check to see if composition would be more appropriate for many of these situations.

Name your objects what they are. Prefer descriptive names and don't be afraid to make them long.

Your IDE should help you follow chains of extension.

name withheld out of cowardice
Wednesday, February 25, 2004

And with respect to buttons, Why do you need so many types of buttons? Bear in mind that I am coming from a Java (Swing) perspective here, but aren't most of the button types you need (Regular, radio, checkbox, toggle etc.) already defined in the libraries you are using. For me the distinction in appearance and behavior are achieved by using different arguments in the constructor or setting members such as the graphic displayed on the button and the command the button implies.

name withheld out of cowardice
Wednesday, February 25, 2004

> ordering in the class browser wouldn't be an issue

Says you. Next time you says it maybe you could do so more loudly so that the IDE authors can hear.

Wednesday, February 25, 2004

Uh, get a better IDE? The class view and object browser in Visual Studio .NET 2003 show a tree view of namespaces with the types as its leaves.

Chris Nahr
Wednesday, February 25, 2004

> Uh, get a better IDE?

Says you. Next time you says it maybe you could do so more loudly so that those who have to pay for these things can hear.

Thursday, February 26, 2004