Interface naming convention [closed]

Answer 1

You may add the word "Interface" as a suffix to your customized interface for example "SerializerInterface". For abstract class, "Fruit", for instance, "FruitAbstract" or you can make it "AbstractFruit", just be consistent all through out. That is readable enough, or follow the usual naming convention.

Answer 2

It looks Hungarianish to me. Hungarian is generally considered a menace in strongly-typed languages.

Since C# is a Microsoft product and Hungarian notation was a Microsoft invention, I can see where C# might be susceptible to its influence.

Answer 3

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.

Answer 4

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.

Answer 5

There is nothing wrong with NOT using I convention for interfaces - just be consistent and make sure it works not just for you but for whole team (if there is one).

Answer 6

The fact of the matter is that everyone understands it and part of writing better code is making it easy to read and understand.