When inheriting from a class in C#, which naming convention is preferred?

Question

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?

Answer 1

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:

System.Object 
  System.MarshalByRefObject
    System.ComponentModel.Component
      System.Windows.Forms.Control
        System.Windows.Forms.ScrollableControl
          System.Windows.Forms.ContainerControl
            System.Windows.Forms.Form

Form is called Form and not ContainerControlForm :)

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.