«

Increasingly I am seeing people prefixing interface names with an 'I', in
open source apps and in example code on the web. So instead of this:

public interface MyInterface
{
}

we have this:

public interface IMyInterface
{
}

Personally, I really dislike this naming convention. Now, some of the
people who are doing this aren't stupid, so I was wondering if anybody has
a good explanation for why this is a good idea? Is it symptomatic of an
addiction to Hungarian notation, or this there some more sensible
rationale?

Dan.

--
Daniel Dyer
http://www.dandyer.co.uk

"Daniel Dyer" <> writes:
>public interface IMyInterface

I often declare interfaces with one method, and then it
is the most natural convention for me to name the interface
like the method, e.g.,

interface Accept<T>{ void accept( T t ); }

Everything else makes you guess more often
(»Closeable« or »Closable«?)

Sun does not seem to prefer »-able« anymore:

»Interfaces

Interface names should be capitalized like class names.

interface RasterDelegate;

interface Storing;«

http://java.sun.com/docs/codeconv/ht...ions.doc8.html

Daniel Dyer wrote:
> Increasingly I am seeing people prefixing interface names with an 'I', in
> open source apps and in example code on the web. So instead of this:
>
> public interface MyInterface
> {
> }
>
> we have this:
>
> public interface IMyInterface
> {
> }
>
> Personally, I really dislike this naming convention. Now, some of the
> people who are doing this aren't stupid, so I was wondering if anybody has
> a good explanation for why this is a good idea? Is it symptomatic of an
> addiction to Hungarian notation, or this there some more sensible
> rationale?
>
> Dan.
>
> --
> Daniel Dyer
> http://www.dandyer.co.uk

I think that it comes from C#. Personally, I really don't see a
problem with a little Hungarian Notation in regard to interfaces.

On Thu, 07 Sep 2006 22:11:36 +0100, parkerc <> wrote:

> I think that it comes from C#. Personally, I really don't see a
> problem with a little Hungarian Notation in regard to interfaces.

OK, but what advantages does it have over not prefixing the interface name
with an 'I'? I'm assuming that there must be some perceived advantage
otherwise it would be completely pointless.

Dan.

--
Daniel Dyer
http://www.dandyer.co.uk

Daniel Dyer wrote:
> On Thu, 07 Sep 2006 22:11:36 +0100, parkerc <> wrote:
>
>> I think that it comes from C#. Personally, I really don't see a
>> problem with a little Hungarian Notation in regard to interfaces.
>
> OK, but what advantages does it have over not prefixing the interface
> name with an 'I'? I'm assuming that there must be some perceived
> advantage otherwise it would be completely pointless.
>
> Dan.
>
> --Daniel Dyer
> http://www.dandyer.co.uk


Its a hang over from the days when Microsoft introduced COM in C++. and
then languages like Delphi took it up also.

As there is no such thing as an interface in C++, it was deemed 'a good
idea' at the time as it differentiated or at least highlighted that
there was a complete set of Pure Abstract Classes in the API, rather
than the traditional Abstract Base classes.

Aside from C++, where I can just about see how it might help some people
see that they should not put implementation inside the (interface)
classes, for language like Delphi that support Interfaces - its a
complete waste of time.

Andrew

parkerc wrote:
>
> I think that it comes from C#. Personally, I really don't see a
> problem with a little Hungarian Notation in regard to interfaces.
>
IMO its one of the silliest ideas ever to infect programming.

The problem is that it completely destroys information hiding by forcing
implementation details to be included as part of all variable and
function names. Change the internal representation of a variable or the
return value of a function or method and you have to change its name and
then churn through all your source, changing all references to the name.
Stupid. It can just about be made to work with ANSI C, but it is
completely at odds with any language that supports overloading.

The best explanation for its existence is that M$ came up with the idea
to paper over deficiencies in its early compilers' type checking. If you
use "Hungarian notation' in its full rigor *you* are the type checker,
not the compiler. This seems like a perverse role reversal to me.

For sensible ideas about naming, source layout, and programming in
general you can't do much better than get a copy of "The Practice of
Programming" by Brian Kernighan and Rob Pike. Its ideas are applicable
to just about any programming language and it contains reasonably
substantial examples in C, C++ and Java to prove it.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |

"parkerc" <> wrote in message
news: ups.com...
>
> Daniel Dyer wrote:
>> Increasingly I am seeing people prefixing interface names with an 'I', in
>> open source apps and in example code on the web. So instead of this:
>>
>> public interface MyInterface
>> {
>> }
>>
>> we have this:
>>
>> public interface IMyInterface
>> {
>> }
>>
>> Personally, I really dislike this naming convention. Now, some of the
>> people who are doing this aren't stupid, so I was wondering if anybody
>> has
>> a good explanation for why this is a good idea? Is it symptomatic of an
>> addiction to Hungarian notation, or this there some more sensible
>> rationale?
>
> I think that it comes from C#. Personally, I really don't see a
> problem with a little Hungarian Notation in regard to interfaces.

A point of clarification, this is *NOT* Hungarian notation. This is an
example of type-based naming, which, Micro$oft incorrectly labelled as
Hungarian.

True Hungarian naming defines prefixes for names based on what the item
represents. Type-based naming defines prefixes based on the data type in the
programming language.

So for example if we had a variable that contained the height of a screen
whose data type in C were unsigned long, then possible names in the two
conventions would be:

Hungarian - hgtScreen
Type naming - ulScreenHeight

The problem is that there is little value in type-based naming. Imagine if
you also had an unsigned long screen color. If you tried to assign this to
the above variable in type based-naming it might look like:

ulScreenHeight = ulScreenColor;

The statement makes no logical sense, but the type-based naming prefix
didn't tell you anything. Compare thiw with Hungarian:

hgtScreen = clrScreen;

One of the main problems with type-based naming is that types can change.
For example in Windoze there is wParam which ceased being a word ages ago,
but they couldn't change the name without breaking users.

Hungarian is not nearly as usefull in an OO language, but it is not as bad
as you were lead to believe from M$'s misuse of the term.

The I convention is relatively harmless, but offers little, if any, benefit.
In addition to the origins in COM as others have mentioned, Eclipse also
uses this convention. According to their convention guidelines, "This
convention aids code readability by making interface names more readily
recognizable." I don't find it necessary myself.

One reason it is used is to simplify naming of interfaces and concrete
implementations of that interface so you can have IFoo interface and the
concrete implementation could be called just Foo. I'll leave it up to you to
decide if this is a good thing or not.

--
Dale King

AndrewMcDonagh wrote:
> Daniel Dyer wrote:
>> On Thu, 07 Sep 2006 22:11:36 +0100, parkerc <> wrote:
>> OK, but what advantages does it have over not prefixing the interface
>> name with an 'I'? I'm assuming that there must be some perceived
>> advantage otherwise it would be completely pointless.

> Its a hang over from the days when Microsoft introduced COM in C++. and
> then languages like Delphi took it up also.
>
> As there is no such thing as an interface in C++, it was deemed 'a good
> idea' at the time as it differentiated or at least highlighted that
> there was a complete set of Pure Abstract Classes in the API, rather
> than the traditional Abstract Base classes.
>
> Aside from C++, where I can just about see how it might help some people
> see that they should not put implementation inside the (interface)
> classes, for language like Delphi that support Interfaces - its a
> complete waste of time.

..NET uses it too.

I can actually see one usage for it in C#, because the syntax
for extends and implements are the same in C# it can make
a class easier to read.

Arne

Dale King wrote:
> A point of clarification, this is *NOT* Hungarian notation. This is an
> example of type-based naming, which, Micro$oft incorrectly labelled as
> Hungarian.
>
> True Hungarian naming defines prefixes for names based on what the item
> represents. Type-based naming defines prefixes based on the data type in the
> programming language.
>
> So for example if we had a variable that contained the height of a screen
> whose data type in C were unsigned long, then possible names in the two
> conventions would be:
>
> Hungarian - hgtScreen
> Type naming - ulScreenHeight

Wikipedia actually mentions both as being hungarian
(system and apps respectively).

http://en.wikipedia.org/wiki/Hungarian_notation

I would say that the MS way of using the word is so
common, that it is the meaning of the word today.

Arne

Martin Gregorie wrote:
> parkerc wrote:
> >
> > I think that it comes from C#. Personally, I really don't see a
> > problem with a little Hungarian Notation in regard to interfaces.
> >
> IMO its one of the silliest ideas ever to infect programming.
>
> The problem is that it completely destroys information hiding by forcing
> implementation details to be included as part of all variable and
> function names. Change the internal representation of a variable or the
> return value of a function or method and you have to change its name and
> then churn through all your source, changing all references to the name.
> Stupid. It can just about be made to work with ANSI C, but it is
> completely at odds with any language that supports overloading.
>
> The best explanation for its existence is that M$ came up with the idea
> to paper over deficiencies in its early compilers' type checking. If you
> use "Hungarian notation' in its full rigor *you* are the type checker,
> not the compiler. This seems like a perverse role reversal to me.
>
> For sensible ideas about naming, source layout, and programming in
> general you can't do much better than get a copy of "The Practice of
> Programming" by Brian Kernighan and Rob Pike. Its ideas are applicable
> to just about any programming language and it contains reasonably
> substantial examples in C, C++ and Java to prove it.
>
>
> --
> martin@ | Martin Gregorie
> gregorie. | Essex, UK
> org |

Great book.

Hungarian notation makes for ugly code - anyone who did any Win32 C++
programming should remember this (any a good deal of people still doing
WinForms C# coding). I still think that adding an "I" to an interface
is not all that bad if it helps the person coding the app to produce
code that he or she can more easily read.

http://web.umr.edu/~cpp/common/hungarian.html - this is evil.

typedefs can also get pretty nasty in C. Especially typedefs of
structs that have typedefs of structs that have typedefs...