Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?


migration rejected from Aug 9 '15 at 18:14

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as primarily opinion-based by durron597, MichaelT, gnat, GlenH7, Snowman Aug 9 '15 at 18:14

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

Is it a DogAnimal or just a Dog? – Anthony Pegram 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. – Anthony Pegram Sep 3 '11 at 16:04

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.


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.


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.


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.