Prefix/suffix for classes

Question

When you write an app that will have vast number of classes, do you use prefixes/suffixes for your class names? Or should I just rely on the namespaces I already define?

In my case, I have classes like:

Blur
Contrast
Sharpen
Invert
...

I just don't know what I might have tomorrow, and want to be collision free as possible with the frequent used classes in the BCL.

Any ideas?

Answer 1

I would say don't use prefixes or suffixes for the names -- that's very close to hungarian notation, which is widely regarded as bad, even by the creators of it at MS. The sole exception to this rule is interfaces, which many regard as OK to prefix with I, but I am of the opinion that interfaces shouldn't have a prefix either. You should group classes that are related into namespaces to prevent collisions.

Answer 2

Namespaces were invented exactly to solve this problem. Use them.

Answer 3

I am curious. Shouldn't those be method names instead of class?

Answer 4

Generally, I would name them something descriptive (like you have) but I split them up into appropriately named namespaces.

In your case, I'd heave something like

namespace AppName.ImageOperations
{
    public class Blur{...}
}

Answer 5

If you have a common base class or an interface (e.g. class Effect or interface IEffect), then I would probably use Effect as a suffix for these classes.

Otherwise I tend to use namespaces.

Answer 6

At work we use prefixes for all classes and some classes use suffixes. This does stop BCL collisions but in my opinion it is unecessary. You are better off using sensible naming and good namespaces.

I would suggest using an I prefix for interfaces, but it is just a personal preference.

Answer 7

Avoid prefixing or suffixing classes unless:

• It is an interface: IFilter
• You need to communicate that it is participating in a pattern: GaussianBlurStrategy
• (from marc_s) You create a custom exception: ImageDoesNotSupportFilterTypeException
• Sometimes to communicate if something is an abstract base class: FilterBase

I'm torn on that last one. I don't like seeing the Base suffix, but it's really hard for a consumer of your API to know that they can't instantiate Filter (without trying it first) based on the name. I have no love for it, but it's a convention that I use.

EDIT

Per Jon B's comment, suffixing custom delegates with Handler is common (FilterExecutedHandler(object sender, FilterEventArgs e);). Although a delegate declaration isn't a class per se, it can cause name collission so should probably be stated here.

Answer 8

Actually I could care less about prefix/suffix and more about Namespace partitions and Class names. I want Class names to be meaningful, but I also want correct Namespaces as to avoid collisions and to unify my companies code base.

Ex.

namespace Company.Department.Product
{
     public class Class
     {}
}

This makes it very easy to partition code out, and help programmers decide where to put functionality. It takes more time to setup, but I feel in the end it's worth it.

Answer 9

The Guidelines for Names (from Microsoft) is an interesting read...

For Namespaces they say:

The general format for a namespace name is as follows:

<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]

For example, Microsoft.WindowsMobile.DirectX

For Classes, one thing they say:

Do not give class names a prefix (such as the letter C).

Interfaces, which should begin with the letter I, are the exception to this rule.

Worth at least a scan through to pick up some ideas...