Interface Naming Conventions

We programmers tend to have a few OCD qualities and there are a few things about C# interface naming conventions that we talked during episode 1 of the podcast about I’d like to whine about discuss.

Microsoft has done a wonderful thing by pushing coding conventions and consistency along with the language of C#. Visual Studio even has a built in code formatter.

 

The Go language has taken it even farther by bundling gofmt, a code formatting executable, with their compiler. The handful of flags are a breeze compared to the handful of checkbox-filled tabs in VisualStudio.

No more arguments over tabs vs spaces!

The C# Coding Conventions do a great job of summing up the reasons for such standards:

• They create a consistent look to the code, so that readers can focus on content, not layout.
• They enable readers to understand the code more quickly by making assumptions based on previous experience.
• They facilitate copying, changing, and maintaining the code.
• They demonstrate C# best practices.

Not a M$FT fan? How about a quote from one of the sacred texts:

It is NOT enough to learn the elements and rules of combination; one must also learn the idiomatic usage

– Frederick P. Brooks Jr
The Mythical Man-Month: Essays on Software Engineering

The only official guidelines for interfaces that I could find from Microsoft were in the Design Guidelines for Class Library Developers:

• Name interfaces with nouns or noun phrases, or adjectives that describe behavior. For example, the interface name IComponent uses a descriptive noun. The interface name ICustomAttributeProvider uses a noun phrase. The name IPersistable uses an adjective.
• Use Pascal case.
• Use abbreviations sparingly.
• Prefix interface names with the letter I, to indicate that the type is an interface.
• Use similar names when you define a class/interface pair where the class is a standard implementation of the interface. The names should differ only by the letter I prefix on the interface name.
• Do not use the underscore character (_).

So what’s the problem?

 

Here’s the Beef:

Inconsistent Hungarian Notation

The “I” prefix is an example of Hungarian notations. This is not consistent with the rest of the coding guidelines and it stands out like a sore thumb. It looks especially strange when the first character of your class is an “I”. Like IISAPIRuntime and IItem.

The Letter “I”

“I” is the 9th letter of the alphabet. You can’t keep your interfaces in the same directory so any properly named interfaces will probably end up of showing up in the midst of your classes.

Additionally, you can’t keep your interfaces in a separate directory without changing the namespace or having your directory structure mismatch your namespace. Resharper squiggles about this.

The squiggles drive me crazy.

We programmers tend to have a few OCD tendencies and this a dripping faucet, a pebble in our collective shoe. This is like fingernails on a…

Okay, so it’s really not a big deal. The convention is much older than .Net. It’s well followed and the consistency is absolutely worth the minor cosmetic glitches.

So, we move on.

Drip.

Drip.