sfeldman.NET

It has become a pretty standard notation across the organizations I work for.

A couple of reasons that I think the "I" naming convention works well.

1. When mixing the interfaces and classes in the same namespace it works as a differentiator.

2. When having an Interface for Customer and a concrete object for Customer what do you call the class?   ConcreteCustomer?  I think it makes coming up  about names easier when you have a convention like interfaces are named with "I".

Jon

I prefer I because with intellisense all of the visible interfaces are all close together. that alone saves a lot of time.

Also, it goes along with the whole "code for the next developer" mentality because I<name> is the convention throughout the .NET framework, and is more discernable by another developer looking at your code.

We use "I", if only because Microsoft says to:

msdn2.microsoft.com/.../ms229040.aspx

Today many people think about Visual Studio and alikes when they talk about .Net code. But many a time, you may open the file in notepad or notepad++ etc. It makes a lot of sense having the "I" notation because looking at a piece of code, you are able to differentiate between a Class or Struct or Interface.

I also prefer the "I" prefix nameing convention.

1. For intellisense

2. For differentiation

I've also read the same book and found the Java notation confusing at first.

Short answer: To "I".

One and for me the most important reason: try to find different name for class and interface, so short like with one "I",  so simple to fast understand aim of it, and so "standardized".

Even the Apple camp has converted to this notation long time ago,  IMac, Ipod, Iphone, etc   are interfaces in their own right.  Google next :)  IGooggle...

I also like the "I" naming convention, but how do you name a generic class based on an interface?

See the example below. "ICustomerCollection" feels like an incorrect name because the collection itself isn't an interface.

It also seems wrong to name it CustomerCollection because a "Customer" could be some completly different implementation not even inheriting from the ICustomer interface.

public interface ICustomer

{

}

public class ICustomerCollection : Collection<ICustomer>

{

}

I normally have and I in front of my interface. I feel it makes it easy to understand that this is an interface.

In JAVA interfaces the "I" prefix is almost never used for interfaces. Take the documentation of SUN for example: java.sun.com/.../interface.html

While discussing with JP Boodhoo why he stopped to use the I notation for the interfaces, I think we

I think I is OK for interfaces.

But I really don't like naming conventions for namespaces and functions. Camel should be better for them.

"I" is not cool........in java, smallTalk or ActionsScript.  Interfaces give us polymorphism for an instance of a subclass.   You are basically casting these subclasses to a common object that overrides super functionality.  Lets be OOP and object oriented.

Naming should follow function and not to confuse. So how about this.

CustomerClass - superClass

Customer - interface

CustomerRetail - subClass

CustomerWholesale - subClass

CustomerOnline - subClass

a= Customer(new CustomerRetail());

b= Customer(new CustomerWholesale ());

c= Customer(new CustomerOnline ());

you really want to cast them to common sort of base functionality as to what they have in common.