IDisagree

| 2 Comments | 1 TrackBack

Jeremy D. Miller talks about how he dislikes the "I" prefix on interface names and how he'd prefer to ditch it in the same way he's ditched most other hungarian notation. I'm all for ditching hungarian but I actually quite like the "I" prefix; though I no longer read it as "this is an interface" but simply "this is what I do". In other words my interfaces, called things like IManageUsers simply clearly state what they do, classes that implement the interface manage users; the class definition is saying "I Manage Users"!

To this end I usually find that my interface names take the form I-Verb-Noun. Whereas my class names often take the form C-Noun-Verb. So IManageUsers would often be implemented by a CUserManager or CMockUserManager, or CNullUserManager... Whilst I do consider the "C" to be a hungarian throw-back wart I don't feel the same for the "I". [Pretty much the only warts that I use on names these days are I, C, p and m_, I can see the sense in Jeremy's suggestion that C, p & m_ aren't really required but I have too much history with them for them to be an easy habit to shake...]

1 TrackBack

Jeremy dislikes Interface names that being with 'I' ("ISerializable"..). Len Holgate disagrees with him,... Read More

2 Comments

Len you must then like the so-called Provider design pattern. e.g. class SessionProvider. New (.NET) MS naming conventions obviously eliminate Hungarian notation.

The 'I' is ugly, but it seems to be just a part of the problem of lack of namespaces in IDL (I'm not using .NET, but I am using COM). I just don't see that there is any way around having really ugly names all over the place.

All of my IDL is generated from UML using a code generator and it's a real pain.

Apart from stuff the code generator has to do to give some chance of things working I still tend to use m_ as well, but include g_ for globals (when I need them), c_ for constants and often t_ for typedefs.

I'm pleased to have shaken the C on class names.

Leave a comment