Dropping the 'I' from interface names?

Via a blogentry by Jimmy Nilsson I ended up on a plea for dropping the 'I' from interface names by Ingo Lundberg. Interesting read and reasoning, I'd say.

In a way you can say, prefixing type names is a form of hungarian coding. But, is that really bad? I'm leaning towards 'no, that's not bad at all'. I agree with Jimmy here that not having the 'I' prefix on an interface name makes it harder to interpret the code when reading it.

Humans are lousy code interpreters. Give 10 programmers a fairly long piece of code to read and you'll get 10 different answers to the question "What exactly does the code do?". The root cause of that of course is that a human being has to keep track of a stack, local variable values, object instances and their contents, while reading, and interpreting, the code. Some will say: "So [censored] what!?!!!11". Well, programmers are humans, and to understand what a programmer wrote, the programmer has to be able to read back his/her code and interpret it the way it will be run at execution time. This is essential to be able to spot bugs early on and to be able to write more solid code. This leads to the conclusion that it is essential that the human being reading a piece of sourcecode gets all the help possibly available.

Let's do a little test here.
Example A:

public class Foo: Bar
{
   // great code goes here
}

public class Foo: IBar
{
   // great code goes here
}

In example A, is Bar a class or an interface? Pretty much everyone will say: "Class". Though in example B, pretty much everyone will say IBar is an interface. This is because of the little hint available in example B which is absent in example A: the I prefix.

The "I" prefix helps the reader of the code to solve ambiguity in the code: is 'Bar' a class or an interface? And solving ambiguity is the key aspect of making code more readable: as long as there's no question what a piece of code represents, the reader of the code won't make mistakes interpreting it and thus less bugs will be the result (unless the developer is not that erm... skilled, but that's a different topic ).

"But... why not use hungarian coding as well then?". That's a fair question, and I think, that hungarian coding as a coding style isn't that bad at all, as long as it is consistently used and everything is defined up front before programming begins. The main drawback of hungarian coding is that if a variable changes type. For example: you first return an ArrayList from a property getter, but now you have this killer BindableArrayList and you return that from the property now, after refactoring. Your variable receiving the property value now has the wrong prefix. This is cumbersome and can lead to sloppyness, where the prefixes aren't updated. To prevent this, prefixes of variable names aren't recommended.

With interface definitions and class definitions this is different. An interface isn't something you would change into a class all of a sudden or vice versa: an interface represents a type definition, a class represents a type implementation and a type definition. That's also why for example abstract classes don't have a prefix 'A', as they are in the same league as a normal class and can easily be converted to a non-abstract class if you want to, which means that you then have to remove/add prefixes everywhere you use that class. Nevertheless, you could opt for that prefix of course, if it helps you understand the code better. Though I disagree with Ingo that an abstract class is close to an interface. An abstract class contains a type implementation, something an interface always lacks. It's that implementation which makes an abstract class worth using, as a common base class for example, which isn't fully implemented but contains the necessary plumbing code for a given interface (be it the class type or an implemented interface or set of interfaces).

Now, of course, using an "I" prefix for interfaces and a "Attribute" suffix for attributes isn't very consistent. Why not use a "Interface" suffix on interfaces instead? Or a "A" prefix for attributes? As Ingo explains: The "I" prefix comes from the COM world, so in a way, a form of tradition, and something a lot of people are already familiar with. So in way it makes sense to inherit that aspect: it's a helper hint a lot of people understand and thus makes reading code more reliable for these people. After all, we lousy interpreters can use every help we can get .