Interface naming convention [closed]

Conventions (and criticism against them) all have a reason behind them, so let's run down some reasons behind conventions

• Interfaces are prefixed as I to differentiate interface types from implementations - e.g., as mentioned above there needs to be an easy way to distinguish between Thing and its interface IThing so the convention serves to this end.

• Interfaces are prefixed I to differentiate it from abstract classes - There is ambiguity when you see the following code:

  public class Apple: Fruit

  Without the convention one wouldn't know if Apple was inheriting from another class named Fruit, or if it were an implementation of an interface named Fruit, whereas IFruit will make this obvious:

  public class Apple: IFruit

  Principle of least surprise applies.

• Not all uses of hungarian notation are censured - Early uses of Hungarian notation signified a prefix which indicated the type of the object and then followed by the variable name or sometimes an underscore before the variable name. This was, for certain programming environments (think Visual Basic 4 - 6) useful but as true object-oriented programming grew in popularity it became impractical and redundant to specify the type. This became especially issue when it came to intellisense.

  Today hungarian notation is acceptable to distinguish UI elements from actual data and similarly associated UI elements, e.g., txtObject for a textbox, lblObject for the label that is associated with that textbox, while the data for the textbox is simply Object.

  I also have to point out that the original use of Hungarian notation wasn't for specifying data types (called System Hungarian Notation) but rather, specifying the semantic use of a variable name (called Apps Hungarian Notation). Read more on it on the wikipedia entry on Hungarian Notation.

The reason I do it is simple: because that's the convention. I'd rather just follow it than have all my code look different, making it harder to read and learn.

Well, one obvious consideration would be the (very common) IFoo and Foo pair (when abstracting Foo), but more generally it is often fundamental to know whether something is an interface vs class. Yes it is partly redundant, but IMO is is different from things like sCustomerName - here, the name itself (customerName) should be enough to understand the variable.

But with CustomerRepository - it that a class, or the abstract interface?

Also: expectation; the fact is, right or wrong, that is what people expect. That is almost reason enough.

Thing is more readable name than IThing. I'm from the school of thought that we should program to interfaces rather than specific implementations. So generally speaking, interfaces should have priority over implementations. I prefer to give the more readable name to the interface rather than the implementation (i.e., my interfaces are named without the 'I' prefix).