Naming conventions for abstract classes

I distinctly remember that, at one time, the guideline pushed by Microsoft was to add the "Base" suffix to an abstract class to obviate the fact that it was abstract. Hence, we have classes like System.Web.Hosting.VirtualFileBase, System.Configuration.ConfigurationValidatorBase, System.Windows.Forms.ButtonBase, and, of course, System.Collections.CollectionBase.

But I've noticed that, of late, a lot of abstract classes in the Framework don't seem to be following this convention. For example, the following classes are all abstract but don't follow this convention:

• System.DirectoryServices.ActiveDirectory.DirectoryServer

• System.Configuration.ConfigurationElement

• System.Drawing.Brush

• System.Windows.Forms.CommonDialog

And that's just what I could drum up in a few seconds. So I went looking up what the official documentation had to say, to make sure I wasn't crazy. I found the http://msdn.microsoft.com/en-us/library/ms229040.aspx">Names of Classes, Structs, and Interfaces on MSDN at http://msdn.microsoft.com/en-us/library/ms229042.aspx">Design Guidelines for Developing Class Libraries. Oddly, I can find no mention of the guideline to add "Base" to the end of an abstract class's name. And the guidelines are no longer available for version 1.1 of the Framework.

So, am I losing it? Did this guideline ever exist? Has it just been abandoned without a word? Have I been creating long class names all by myself for the last two years for nothing?

Someone throw me a bone here.

Update I'm not crazy. The guideline existed. https://docs.microsoft.com/en-us/archive/blogs/kcwalina/i-dont-like-the-base-suffix">Krzysztof Cwalina gripes about it in 2005.

In Framework Design Guidelines p 174 states:

> Avoid naming base classes with a "Base" suffix if the class is intended for use in public APIs.

Also : http://blogs.msdn.com/kcwalina/archive/2005/12/16/BaseSuffix.aspx

Also, if the abstract class has a few static members that will be used, the 'Base' can get ugly.

I don't remember such a guideline. I believe you should use the naming that makes sense. Sometimes the abstract class is only designed to provide common functionality to some classes (as a tool), which I think should have the suffix. However, in some cases, you want to use it as the base of a polymorphism hierarchy which it's not complete itself. In those cases I suggest naming like a normal class.

As you see, you won't probably declare a method that accepts a ButtonBase as parameter. It's designed to provide minimal functionality for subclasses. However, you might treat a ConfigurationElement as an entity that has different forms but it is not complete on itself (and hence it's abstract)

Sometimes Base is still necessary, especially when you provide both a concrete class and an abstract class for someone to extend to create a concrete implementation.
e.g. Controller and ControllerBase (actually Controller is also abstract, but provides signifigantly more functionality than ControllerBase)

Base suffix is ugly when programming against an interface, so I think the Microsoft guideline not to use it applies when the abstract class is predominantly used like an interface. Probably what they mean by Public API.

The point is that there are cases where there is no better alternative to using the Base suffix.

I understand the inclination to avoid a Base-Suffix, but I also understand the need for some Suffix. Now, a Comment of this article suggests using "Type" as a Suffix as second choice to not using any. I believe this to be confusing, but the Idea that "such a non-committal word would tend to indicate that it’s a non-committed class" stuck with me.

As an Alternative: I'd prefer using "Kind" as a suffix to state the object as “of or belonging to a specified race or family” (Wiktionary: -kind).

Example: DataProvider and ReflectiveDataProvider are both DataProviderKind

Inspired by Biology where e.g. "canis lupus" belongs to the family "Canoidea", which very roughly translates to "dog-ish".

Microsoft states, at:

https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/names-of-classes-structs-and-interfaces

"✓ CONSIDER ending the name of derived classes with the name of the base class. This is very readable and explains the relationship clearly. Some examples of this in code are: ArgumentOutOfRangeException, which is a kind of Exception, and SerializableAttribute, which is a kind of Attribute. However, it is important to use reasonable judgment in applying this guideline; for example, the Button class is a kind of Control event, although Control doesn’t appear in its name."

Generally speaking, this implicitly rules out using "Base" in the name.