IFoo as an interface for Foo. It’s short and ugly, it’s only come into being because no one thought it through at the time, and everyone thinks poorly of it even though they may not say so.
If you’re the one doing this, you gotta think – what does it say about you?
Liz Keogh, lunivore 
Yet another naming sin forced upon the world by Hungarian notation. *sigh*
It’s really sad; interfaces are types, pure and simple. The only thing you need to care about is that you can’t instantiate them directly. So why mark them in an ugly way that essentially discourages people from using them?
Of course, there’s a lot of COM programmers who have this ingrained by now.
I think it says that you did the best you could at the time but you have an opportunity to learn and improve.
There is a school of thought that goes “everyone did the best they could do at the time, with the information they had available to them at the time”. To think otherwise is to invite criticism of arrogance. You’ve effectively called everyone who creates an interface prefixed an interface with an ‘I’ stupid – of course if you were simply trying to start an argument that’s another matter…
Sam, http://www.magpiebrain.com/
It might say that you are writing C# code and are being consistent with the coding conventions used in that language.
I like IFoo.
I wouldn’t say stupid, but perhaps ignorant. There were certain projects on which I was working in which, in my innocence and under the instruction of certain supervisors, I used IFoo. (I wasn’t comfortable with it at the time, but I did it anyway).
I now know better. I wish to pass my new-found wisdom on, in the hopes of eliminating IFoo entirely.
All right, so I like arguments too. 🙂
Is C# not an object-oriented language in the same way as Java? Does an interface not describe the relationship between two classes?
If not, then by all means go ahead and use IFoo. Otherwise I would love to have an argument with whoever decided C#’s coding conventions.
(There are some people who use I as a tag for interface, but would not necessarily use IFoo as the interface for Foo. I don’t like it, especially if C# is a strongly typed language and has decent IDEs which can deal with interfaces as effectively as Eclipse or IntelliJ, but I can understand it.)
I like extra-hot chilli powder, ginger, garlic, anchovies and slices of lime with the rind still on. You can help me with my code if I get to cook.
What do you think is more important? Using the conventions that you prefer? Or using the standard conventions of the platform and project?
I think it’s important that an interface describes the relationship between a class and the tool it uses. I don’t see how that can be compatible with IFoo, or indeed any convention which links the name of the interface to that of the class which implements it.
Arguments over the partitions here are increasingly turning me against DefaultFoo, too. There’s a better way out there somewhere.
There is still a strong school of thought that says names should convey typed information, ala Hungarian. In MS-land, for example, you have IFoo and CBar, distinguishing interfaces and classes. Similarly, some people _still_ want to put ‘str’ on the front of Strings.
For myself, I hate it. It smacks of redundant information that I just don’t want. I don’t write multi-page methods: I don’t need type information there in the variable name, when I can see it at the top of the method.
Robert, twasink.net
Anybody who does not work in the conventions used by the project is undoing the team’s hard the work to build a clean codebase with a common domain language. Agile methods stress common code ownership for a reason — it’s extremely hard to work on code that is a patchwork of the individual styles chosen by prima donna programmers. The worst project that I have had the misfortune to work on recently had different coding styles used within individual files! Anbody who does not work with the team in this respect should NOT BE ON THE TEAM, end of story.
Um… I think you’re missing my point. IFoo is used because someone thought of a Foo class and created an interface to go with it. That kind of thinking doesn’t lead to clean code in the first place.
Here’s an example, using the IFoo interface notation:
I create a Gui and an IGui interface, so that the Gui can listen to the events from the Engine, which implements the IEngine interface.
Because of threading issues, I decide to create an EventQueueHandler, which can manage the events passed between one and the other. To enable it to talk to both it now has to implement both the IEngine and the IGui interface.
The EventQueueHandler is neither an Engine nor a Gui.
This is what I’m trying to avoid by hating the use of IFoo. It’s pretty easy to see that this is wrong, but in more complex code the roles can be lost amidst the functionality. What the EventQueueHandler’s actually doing is listening to the ReportEvents fired by the Engine and the RequestEvents fired by the Gui, so it should be implementing RequestEventListener and ReportEventListener, which should also be the interfaces used by the Engine and the Gui respectively.
Call them IRequest… and IReport… if you have to, as per the bottom of my post. If you really have to call them IEngine and IGui then please, throw me off your team.
My preference is not to use the I. If I were working on a team that had a coding standard to preface all interface names with I, I could live with that.
The trouble I see with IFoo is not the presence of the I, but the lack of any other distinction between the name of the interface and the name of the class. Still I worry that the ease of simply adding that I makes it less likely that people will do the work of further distinguishing the names.
What distinguishes Foo from all other IFoo implementers that exist, or that could come to exist? Identify that distinction and put it into the name.
Dale Emery
http://www.dhemery.com
Still I worry that the ease of simply adding that I makes it less likely that people will do the work of further distinguishing the names.
Thank you. I knew there was a reason why I had such a real, deep-down, instinctive dislike of ‘I’, but couldn’t put my finger on it.
I, too, would preface with ‘I’ if I had to, but not before making sure that the rest of the team understood the dangers. (If the code had been around a while before I got there, I’d hope that someone had already done this!)
I think the poster at the top of this subthread was referring to the convention of writing “I” at the start of interface names, not of having more than one interface per class.
I’ve tried to cover that, and explain the differences between using ‘I’ as a tag (which I don’t like, but understand) and using ‘IFoo’ for a ‘Foo’ class (which only works when you have one interface per class, and one class per interface). The first is annoying, but tolerable. The second isn’t just a bee in my bonnet; it’s a wasp. I hate wasps.
The argument has persuaded me to clarify the problem, at least, and taught me why DefaultFoo is just as bad as IFoo (something I didn’t get till I thought it through).