Should We Change the Way We Name Interfaces in .NET?
Comments(28) 
As part of the Nothin But .Net training experience, JP Boodhoo encouraged us to try out a few non-standard naming conventions that has adopted recently.
The one that intrigued me the most was his convention for naming interfaces.
Rather than taking the Microsoft sanctioned approach of adding an I prefix to all interface names, JP adopted the convention used in the Java world of reserving the unadorned name for the interfaces and instead adding an Impl suffix to the end of the concrete classes that implement the interface.
Actually, this was actually not the first time I’ve been exposed to this convention.
I have a vague recollection of Dru Sellers making a similar case for using this convention a few years ago when I worked with him. However it didn’t make nearly as much of an impression on me at that time because I wasn’t in the habit of using interfaces except when I wanted to achieve polymorphic behavior and I had already used up my base class.
Since then I started using interfaces for almost everything except entity classes. I first went down that path out of necessity because it was a requirement of Rhino.Mocks, but after I started reading about the SOLID principals and getting a better understanding of the benefits of loose coupling I adopted the approach as a de facto design guideline.
Now that interfaces play a much more central role in my code, it makes perfect sense to me that they should take precedence over concrete types when striving to create names that make my types more readable.
It also strikes me as odd that the naming standard for interfaces is clearly a vestige of the days when Hungarian notation (e.g. strName, intAge) ruled supreme. If Microsoft actively discourages the use of Hungarian notation in the case of every other type, then why should this one be any different?
When I first considered the possibility of going against the Microsoft standard, I worried about the confusion it would cause for future developers.
However, my experience in the course was that it was only confusing for the first day and then I actually grew to like it once I internalized the convention and started relying more on my color scheme of my IDE to immediately distinguish interfaces from classes.
I especially liked how the new convention served as a constant reminder of the central role that interfaces should play in my design.
Is anyone else out there using this convention?
Is it folly to swim against the stream in this regard?
Popularity: 4% [?]
First of all, I want to defend the core idea of Hungarian notation. The idea was not to prefix variable name with type (String, int, etc.) but with variable _kind_ (safe string, unsafe string, etc.). And the kind prefixes are damn cool. Imagine some asp.net view with many properties to bound to the view. Safe strings are named sSomething and unsafe (that need html encoding) – uSomething. That’s really useful and damn good. So just don’t blame the idea looking at it’s implementation
As for me the ISomething notation is a VERY cool thing. The SomethingImpl name, first of all, not fitting naming convention for classes and look ugly (imho). Second, it places the focus from your implemenation to your interface. Yes, if you have only one implementation for each interface that may play well. But what if you have several implementations? FirstSomethingImpl, SecondSomethingImpl?
I do think interfaces are an extremely important part of good design, but the real accent should be placed to interface implementation.
ISomething is the best!
Agreed!
What if a class implements a number of interfaces? Do you call it Interface1Interface2Interface3Impl?
The I prefix is much much better.
Drop the ‘i’ it is a sacred cow that needs to be slaughtered. Name the class what it is, name the interface what it is.
I am not a fan of the ‘Impl’ suffix because it doesn’t tell a story. I usual use XxxxxDefault or better yet if the interface is EncryptionService then the concrete class is DesEncryptionService. The implementing class is usually more specific than the interface.
booyeah, glad to see you on this side of the awesome!
-d
@Ivan – interesting take on Hungarian notation. My guess is that the majority of C# developers are not dealing with unsafe strings that often. At the very least, it seems like safe strings should be the default in your convention so you would only prefix a “u” if you are doing interop in C# and never prepend an “s”.
@Ivan & @Eric – That is a very good question about how the Impl suffix works with multiple classes. I like Dru’s approach (see next comment) of trying to always pick a logical name instead of using the “Impl” suffix. When you only have one implementation, it seems like that might not always be an easy thing to do. However, as you get more implementations, I’m guessing that would be much easier to pick logical names because the distinguishing characteristics would be more obvious.
@Dru – I like the idea of picking a logical name whenever possible and “Default” is definitely clearer than Impl.
@Russell
It’s not only about the rather rare interop, it’s actually a common task to decide whether some field should be HTML encoded or not. But yes – by default your strings should be safe, that’s a good notation choice.
Dru’s approach for naming could play well. Perhaps I’m more against the ‘Impl’ suffix rather than loyal to the ‘I’ prefix. Thus having Manager as an interface and ProductManager/ShipManager/PersonManager as implementation looks not bad. But, but – how will we distinguish abstract classes and interfaces in this case? Maybe ManagerBase or BaseManager could serve as abstract class.
Manager < ManagerBase < ProductManager ?
Not bad
I don’t use the Impl suffix either, but when interfaces represent Action or Capability, I remover the ‘I’ prefix because it is clear it could not be a class.
I would chose ‘Disposable’ instead of ‘IDisposable’ since there is no risk of a Disposable class.
For service interfaces, I still use the ‘I’ prefix for the interface and no suffix for the implementation…
I find the “impl” suffix aesthetically lacking. That’s a nice way of saying it’s ugly. I do not have a problem with the “I” prefix. It makes it very clear what the canonical interface is, so that the implementers can be named according to their role without concern for the interface name.
Alan
@Ivan – Thanks for clarifying about safe strings also being related to things like HTML encoding. That makes more sense.
I like the Base suffix if you are trying to share functionality between classes.
However, I’ve seen lots of people use abstract classes to just enforce a contract, in which case just an interface would work better. I’ve also seen some hideous inheritance abuse where efforts to share functionality cause way more problems than they solve because the logic gets more convoluted as more derived classes get implemented just to make the shared method work in every case.
That’s why I often prefer to go the interface route instead of the inheritance route when possible.
@Alan – I now concede on the butt ugliness of the “Impl” suffix (see my response to Dru’s comment below). However, I wonder how much of the aesthetic liking of “I” comes from what we are used to. Does “I” look good because that is what we are used to or does it logically convey the most meaning?
The “I” is also better self documentation. If I have a method DoSomething – DoSomething(IFoo bar) tells me only an interface is required – DoSomething(Foo bar) looks like I can only use Class Foo. And then, if I have a method taking both a custom interface and framework interface I’d have DoSomething(Foo bar, IAsyncResult ar) which is confusing.
I think its valuable to have a convention separating Interfaces from Classes.
I agree with @Alan that the “Impl” suffix is ugly, and I don’t think it adds any value in the (common?) case that there is a single non-mock implementation of a given interface. @ErikTheRed has a good point too.
The “I” prefix can be ugly as well, especially when the interface name also starts with an I, but it’s both shorter AND the reigning convention. I like the idea of a naming convention that promotes interface-driven design, but I don’t think the Java convention provides enough valuable to go against the .NET grain.
Impl is ugly so totally agree with everyone there. In a world of not shortening things down anymore it doesn’t make sense to call it impl, it should be Implementation. So for interface Car it would be CarImplementation and that just sounds kind of useless to me.
DefaultCar seems like a better use. Or SimpleCar. Or whatever… just not Impl.
No seriously what is wrong with the ‘I’ prefix? You can’t just change the mindset of developers 8 years after they have been using the ‘I’ prefix for interfaces.
[...] Should We Change the Way We Name Interfaces in .NET? – Russell Ball talks about an alternative to the IInterface naming convention taken from the Java world which expresses the interface as the key concept and the implementation class as a second class citizen (in naming terms) [...]
@Gabriel – The time that a standard is used doesn’t seem like a compelling argument to me. I believe that Hungarian notation was used for longer than 8 years, yet as a developer community we (at MS’s prompting) dropped it anyways because we decided that it no longer reflected the state of our tools or the goals that were were aiming to achieve (readability).
I am just saying that there is absolutely no reason to change the naming convention especially looking at the Base Class Library where thousands of interfaces are defined with names starting with ‘I’.
Another good idea is to use the ‘able’ postfix like a serializable, stackable and so forth.
Well now that we are talking about naming conventions, how about a convention where the only PascalCase is Class and Interface names? Everything, and I mean everything else is lowercase (including properties, methods, variables, and even namespaces). Namespaces have no underscores.
Variables, parameters, properties, and methods all have a casing similar to “get_the_trades”. All lowercase with “_” (underscores) between words.
http://bombali.googlecode.com/.....ltTimer.cs
@Robz – Yeah, the lowercase & underscore convention comes from Ruby, so I have had a chance to use that one on a project before this class. I do actually think it is more readable, but I thought I would practice SRP on my post and not mix topics. I also think that the vast majority of .NET developers would put up even more resistance to that one. Perhaps that can be the next post though…
I’m a little bit of a fan of chainsaw naming conventions…
I am a fan of killing the sacred ICow and just calling it Cow and having DefaultCow, JerseyCow and MexicaqnCow. I read something about this last year and thought it would be nice, but didn’t try and introduce it to my team. IInterface naming is a developer “woobie” that they’re definitely not ready to give up yet. I also read some one saying if you must use “I” as a prefixe try making it a pronoun IManageCache, IAuthorizeUsers. Still would like to drop the “I” altogether.
~Lee
[...] Originally posted here: Should We Change the Way We Name Interfaces in .NET? | Caffeinated … [...]
If you are still using the JLam color scheme, interfaces and structs have the same color. Personally, I don’t mind the I prefix. But at the same time, I experiment with different naming conventions and styles. Ulitmately, what is important is that your organization has a standard.
[...] See original here: Should We Change the Way We Name Interfaces in .NET? | Caffeinated … [...]
[...] Should We Change the Way We Name Interfaces in .NET? Discussion on using a different technique for naming interfaces, rather than the typical ISomething. [...]
[...] Should We Change the Way We Name Interfaces in .NET? Russell Ball about dropping the I of the interface names and annotate the implementations with an Impl suffix instead. The first two comments pretty much sum up my current thoughts on this. [...]