Hungarian Notation Should I use it?

[1vRz3TCk]

Duoas wrote:

....but it does make a difference whether you call it true Camel Case or not... I don't remember the other name right now...

I known it as:

thisIsASampleVariable = camel case or lower camel case
ThisIsASampleVariable = Pascal case or Upper camel case

[Duthomhas]

That's what I was thinking but I was not sure...

(Object) Pascal identifiers are typically in "Pascal case" or "Upper camel case", particularly in the standard libraries.

IUnknown -- interface type for "unknown"
TStringList -- string list class
EOutOfRange -- "out of range" exception type

etc.

[hanst99]

On the topic of hungarian notation - if you have anything really important that you think belongs into the name of the variable, fine. But don't do stuff like putting a C before classes and I before interfaces - that's just silly because it doesn't really add any new information.

[chrisname]

@hanst99,
Putting I before interfaces is a good idea IMO because interfaces can't be used as a type while classes can.

[hanst99]

Interfaces can't be used... as a type? Huh? What do you mean? That you can't instantiate them? Codifying interface names is IMHO bad because you are (almost) ALWAYS using the interface to interact with objects (otherwise there would be no point in creating an interface), so you have that interface name all over your code. And everywhere there is an I in front of it to remind you that it is an interface - even though you are always dealing with concrete objects, just without caring about the concrete type. It's not only ugly, but for that reason even (at least to me) misleading.

[chrisname]

Wait, are we talking about interfaces as a concept in and of themselves or interfaces in C++? Because a C++ interface doesn't really exist, all you can do is emulate it with an abstract class where all methods are pure virtuals. In languages that actually have interfaces (or at least, in C# and probably Java) you can't instantiate interfaces and interfaces can't hold methods with definitions (only declarations) or variables. Therefore, they're not a type and they can't be an object, so they should be separated from things that can be objects - enums, classes, structs, etc. All you usually use an interface for AFAIK is to define what methods and properties a group of types needs to implement -- if you have an interface called IDrawable then every drawable object should implement it. There are also reasons why you should use interfaces instead of abstract classes in languages that have them (in C# for example, an object can only inherit from one base class, but it can implement as many interfaces as you want it to).

[helios]

Because a C++ interface doesn't really exist

This is just nitpicking. Purely abstract C++ classes behave exactly As Java and C# interfaces, they're just called differently. It's like saying that C++ functions are different from BASIC subroutines.

you can't instantiate interfaces and interfaces can't hold methods with definitions (only declarations) or variables. Therefore, they're not a type

You must be using some weird definition of "therefore" where the expression on the right doesn't derive from the expression on the left.
Interfaces are classes (more accurately, classes and interfaces belong to the category of [types that can be inherited from]), and classes are types.

[Duthomhas]

hanst99 wrote:

But don't do stuff like putting a C before classes and I before interfaces

You're wrong.

What it adds is that you are dealing with a very specific type, that cannot be handled normally. It is also common to tag type names in some way to distinguish them from variable names.

    TStringList -- this is a class representing a list of strings

Sure, you could have named the type as "StringList", but this case does not cover corner cases:

    Point -- is this a type or an instance?

struct Point
  {
  int x, y;
  Point( int x = 0, int y = 0 ): x( x ), y( y ) { }
  };

int main()
  {
  Point Point( 1, 2 );  // wait... that's wrong... 

By giving types a tag that indicates that they are, in fact, a type and not an object, you make life easier in terms of readability and usability.

By giving types a "this is a type" tag, you make the following much easier to deal with:

int main()
  {
  TPoint Point( 1, 2 );  // oh, I have a Point (type) named "Point". Much easier! 

Oh, and now I don't have to invent other names for a generic item, like "pt" or "APoint", or play with case semantics like Point point( 1, 2 );.

Hope this helps.

[hanst99]

How can an interface not be handled normally? As I said above, handling them is the whole point behind an interface. The only thing you can't do with an interface is instantiating it, but an interface is very unlikely to have a public constructor (I at least have never seen an interface with one), so even attempting to do it is impossible to begin with.

As to the variable names - I personally try to avoid naming a Points point, just as much as I try to avoid naming my Cat cat. Of course sometimes it's hard to figure out a descriptive name (especially if you really don't care what kind of argument you get, like in vector addition), but that doesn't make the example you gave a good one.

[moorecm]

Even adding a T or some other mark to denote user-defined types does not save the developer from looking up the declaration, though. As the life of the project grows, the name of the variable becomes less and less accurate. Consider a large codebase with many libraries written over a long period of time. Tthis or Tthat is not necessarily what a single developer expects it to be. I've mentioned this before, if you have to go look up the declaration, which you always would, it is not doing anything but cluttering up the identifier.

[bbgst]

I agree. In a large project, you can't avoid looking at more than the type of the variable. In a small project, you probably know all the classes and don't need this kind of identification.

[PanGalactic]

Two important innovations are responsible for the decline in use of hungarian notation: a trend towards smaller classes and functions, and Intellisense in editors. Why use bFlag when only three lines above you declared "bool flag;"? And if you are modifying a class and cannot remember the member variable types, your class is probably too big. But these days your editor will tell you what it is by just hovering over the variable name. Do not use hungarian notation. Better tools and coding practices exist today.

[moorecm]

That's exactly right, I didn't think to mention that when I said one has to "go look at the declaration", that means jump to the declaration using tags or some similar IDE feature.

[Duthomhas]

I was going to type in a response to all this, but I really just don't care enough. I've still got to finish fixing the dryer and find whatever died in the closet and read to my kids.

You all just go on believing what you want.