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?
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
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's a convention and everyone has his own.
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
You should not call that a
For the other example: I would consider calling it
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.