Naming Interfaces and Super (Base) Classes

The number of options when choosing conventions for the naming of interfaces and super classes is fairly limited. Like so many other things in programming, naming of these two things is most effective when the names are clear, meaningful and consistent. These three things will stand out far more than the choice of naming convention or spelling.

Interfaces
Of all the items that I'll write about in this series, naming conventions for interfaces will be the easiest. I have only ever seen one way of naming interventions in any project that I've worked on. Not only that, I can't find more than one example of an interface naming convention in books or online. As much as most places suggest PascalCasing and camelCasing for all things, including Microsoft (thanks to the Coding Hillbilly for this....I'll bring a bottle of 'shine to your place next time we go trapping squirrels), nobody seems to be able to shake the Hungarian Notation recommended for interface naming. The only naming convention ever discussed for interfaces says that all interface names should be prefixed with a capital "I" followed by PascalCasing for the remainder of the name.

    9         public interface ICanRefrigerate

   10         {

   11             //some stuff

   12         }

It's pretty simple. Everyone does it.

Super (Base) Classes
Naming conventions for super or base classes should follow the same naming convention used for standard classes. The one difference is that you want to make the names of this type of classes both meaningful and useful as suffixes when they are inherited. In the following example you can see how the Car base class works nicely in both the SuperCar and RacingCar classes that inherit from it. The name of the RacingCar class clearly indicates that it is a "type of Car" or inherited from the Car base class.

   14         public class Car

   15         {

   16             //some stuff

   17         }

   18 

   19         public class SuperCar : Car

   20         {

   21             //different stuff

   22         }

   23 

   24         public class RacingCar : Car

   25         {

   26             //other stuff

   27         }

My Choices
I'm the first to admit that I didn't present many options here. In these cases there aren't many options, no matter how accepted or rejected, to present. I use the "I" prefix for interfaces and I also use the Super/Base class suffixing format as well.

posted @ Tuesday, July 18, 2006 8:00 PM

Print

Comments on this entry:

# re: Naming Interfaces and Super (Base) Classes

Left by Bil Simser at 7/19/2006 4:11 AM
Gravatar
In your example, if you didn't follow the "I" convention for interfaces, how would you tell you're inheriting from a class (Car) rather than implementing the ICar interface. Although you could using RefridgerateInterface instead of IRefridgerate, it's just easier to reader and shorter to type (at least to me). As for base clases, I don't use the term "Super" but rather "Base" so instead of "RacingCar" inheriting from "Car", I would create a CarBase class and RacingCar would derive from it. That way I know if I'm doing something like this: class DoubleDeckerBus : Bus class Bus : CarBase I don't have to look past CarBase because I know its the last class (other than Object, at least in .NET) in the stack. Again, just an added amount of comfort in the readability of my code.

# What's in a name?

Left by Fear and Loathing at 7/19/2006 4:27 AM
Gravatar
I’m really digging the series of blog posts over at Coding in an Igloo(an Emontonian) that cover

# Intersting Finds: July 19, 2006

Left by Jason Haley at 7/19/2006 7:50 PM
Gravatar

# Interesting Finds: July 19, 2006

Left by Jason Haley at 7/19/2006 7:50 PM
Gravatar

# Coding in an Igloo : Code Naming Conventions, The Series

Gravatar
PingBack from http://igloocoder.com/archive/2006/07/04/394.aspx

Your comment:



 (will not be displayed)


 
 
 
Please add 5 and 7 and type the answer here:
 

Live Comment Preview: