To use the 'I' prefix for interfaces or not to

Question

That is the question? So how big a sin is it not to use this convention when developing a c# project? This convention is widely used in the .NET class library. However, I am not

Answer 1

Read this and move on. If you're using Java, follow the Java naming conventions.

Answer 2

You can choose all names in your program how you like, but it's a good idea to hold naming conversion, if not you only will be read the program.

Usage of Interfaces is good not only if you design you own classes and interfaces. In some cases you makes other accents in your program it you use interfaces. For example, you can write code like

SqlDataReader dr = cmd.ExecuteReader (CommandBehavior.SequentialAccess);
if (!dr.HasRows) {
    // ...
}
while (dr.Read ()) {
    string name = dr.GetString (0);
    // ...
}

or like

IDataReader dr = cmd.ExecuteReader (CommandBehavior.SequentialAccess);
if (!dr.HasRows) {
    // ...
}
while (dr.Read ()) {
    string name = dr.GetString (0);
    // ...
}

the last one have looks like the same, but if you are using IDataReader instead of SqlDataReader you can easier to place some parts which works with dr in a method, which works not only with SqlDataReader class (but with OleDbDataReader, OracleDataReader, OdbcDataReader etc). On the other hand your program stay working exactly quick as before.

Updated (based on questions from comments):

The advantage is, like I written before, if you'll separate some parts of you code which work with IDataReader. For example, you can define delegate T ReadRowFromDataReader<T> (IDataReader dr, ...) and use it inside of while (dr.Read ()) block. So you write code which is more general as the code working with SqlDataReader directly. Inside of while (dr.Read ()) block you call rowReader (dr, ...). Your different implementations of code reading rows of data can be placed in a method with signature ReadRowFromDataReader<T> rowReader and place it as a actual parameter.

With the way you can write more independent code working with database. At the first time probably usage of generic delegate looks a little complex, but all code will be really easy to read. I want to accentuate one more time, that you really receive some advantages of using interfaces in this case only if you separate some parts of the code in another method. If you don't separate the code, the only advantage which you receive is: you receive code parts which are written more independend and you could copy and paced this parts easier in another program.

Usage of names started with 'I' makes easier to understand that now we are working with something more general as with one class.

Answer 3

Cannot believe it that so many people hate the 'I' prefix. I love the prefix 'I'. Here is why:

• Are abstract and interface different? Yes
• Do I care the difference as a developer? Yes, but not always.
• When do I need to care?

Design discussion(When I draw on the board, prefix 'I' clearly telling everyone it's an interface) Read existing code(When I see prefix 'I', clearly I know it's an interface. There'are exceptions for words start with 'I', but very few cases)

• Do I always need 'I'? No. But I want consistency, so YES.

With just one prefix 'I', it avoids so much communication overhead.

Answer 4

Best practices override convention sometimes, in my opinion. While I may not personally like the convention, not using it goes against the best practice that has been in place for longer than I care to think about.

I would look at it more from the point of how other people do it, in this case. Since 99% of the common world will be prefacing with the "I", that is good enough to keep this best practice. If you have to bring in a contractor or on-board a new developer, you should be able to focus on the code and not have to explain/defend choices that you made.

It has been around long enough, and is ingrained well enough, that I don't expect it to change in my lifetime. It is just one of those "unwritten rules", better defined as an "unwritten best practice", that will probably outlive me.

Answer 5

conventions exist to help all of us. If there is a chance another .net developer will be working with you then yes, follow the convention.

Answer 6

I think the main reason for the I-Prefix is not that those using it can see it's an interface but that those implementing/deriving from existing classes and interfaces can see more easily wether it's an interface or base class.

Another advantage is that it prevents stupid things like (If my Java memory serves me correctly):

List foo = new List(); // Why does it fail?

The third advantage is refactoring. If you move through your objects and read the code you can see where you forgot to code-by-interface. "A method accepting something with a type not prefixed with I? Fix it!".

I used it even in Java and found it quite usefull, but it always depends on the guidelines for your company/team. Follow them, no matter how stupid you may think they are, some day you will be happy they exist.