Take the 2-minute tour ×

If you inherit from Tile, for example, should the subclass be called CollisionTile or just Collision? What about for painting tools in an application like Paint? PenTool or just Pen?

Are there any published guidelines for this?

share|improve this question
Is it a DogAnimal or just a Dog? –  user414076 Sep 3 '11 at 16:01
@Anthony: Yeah but sometimes the subclass is a really generic word that may be taken or it may not be intuitively obvious as to what the class is. For example, Collision could mean anything. CollisionTile is more obvious. –  Michael Johnson Sep 3 '11 at 16:03
And now I think you've stumbled across the answer. Where it adds clarity, include the base. Where it does not (as the case of Dog), omit it. –  user414076 Sep 3 '11 at 16:04
add comment

migrated from stackoverflow.com Sep 3 '11 at 16:10

This question came from our site for professional and enthusiast programmers.

5 Answers

It depends if you think you will have many different classes of Collision, in which case CollisionTile makes sense if you will also have CollisionOther.

Pen is ok as well instead of PenTool.

there are no written on stones rules, it depends on your actual needs.

Look at the .NET Framework:


Form is called Form and not ContainerControlForm :)

share|improve this answer
Would have been funnier if you would have called it ObjectMarshalByRefObjectComponentControlScrollableControlContainerControlForm :-) –  LarsTech Sep 3 '11 at 16:08
add comment

It's a convention and everyone has his own.

Use Tile << CollisonTile , if there aren't gonna be further child classes. Because in that case, the name of the class gonna get bigger and bigger as the inheritance level grows further.

share|improve this answer
add comment

I believe, refering to inheritance, the proper naming convention is common sense. In inheritance you do not use concatenated values, but common sense names.

For instance, Person -> Client | Agent | Admin. You know all those are a Person, its common sense. or like @Anthony said, Animal -> Dog | Cat | Bird . They are all animals.

Since a class can only inherit from 1 other class, there is no need to name it AnimalDog, because there won't be a PersonDog. If you want to differentiate your Dog from a different class on another assembly also call dog, you use Animal.Dog in declaration, which is a better practice than just naming your Dog AnimalDog.

share|improve this answer
add comment

It sounds like you're creating a Collision Tile, i.e. a tile with collision. If this is the case, the tile should be called CollisionTile.

You should not call that a Collision because a Collision class would be quite different. A Collision class sounds like an event response class, i.e. when your character collides with a tile, an instance of Collision is created with details about the collision.

For the other example: I would consider calling it PenTool if I thought there was any risk that the class might be confused with System.Drawing.Pen. [And of course most drawing apps have twenty different tools so you would want all or none of them to have the Tool suffix.]

There's no mechanical rule for whether you should include the superclass name in the subclass.

However you should simply, unambiguously give the class a name which matches its function.

share|improve this answer
add comment

Although refactoring in C# is quite easy, I would argue against a naming convention that incorporates the name of a parent class in a derived class name.

What if you introduce a new class into the hierarchy? What if you remove a class from the hierarchy? Do you really want to change all the references to derived class names? Do you want to update any program documentation?

Suddenly a local implementation decision (do I derive a class or just delegate functionality to another class) creates multiple non-local changes. It's painful with a large project. It's even more painful if other programmers are consumers of your classes.

Just give the class a name which matches its function (as Chris Burt-Brown suggests). If part of the name happens to be the same name as a parent class, so be it. But regard the class name as a meaningful name, not an implementation description.

share|improve this answer
add comment

Your Answer

