Hungarian Notation POLL

Based on some opinions noted on one of my previous posts I have decided to make a poll deciding once and for all if Hungarian Notation is a good idea, this poll will be the definitive answer and all mankind (that programs in C++) will bow in supplication before the might and truth of this poll (so make it good eh?)

If there was one official standard for Hungarian Notation (as opposed to the myriad variations that exist now) would you use it?

This is what I said the last we did this...

>>>
In all but a couple of special cases, I call my variable Variable or if two or more word SecondVariable, i.e. with each word capitalised. I shorten some words where this does not introduce ambiguity.

Exceptions are loop counters, I always start with a lower case i, then j, and so on - hang over from many years of coding in Fortran. Pointers I call pSomething, hang over from an early database system I used whereby that was a requirement, and for some reason, I call handles hSomething.

Functions follow the same rule as variables.

With todays IDE's, Hungarian is a relic, if I have forgotten what type a variable is, I put my cursor on it and the IDE tells me and offers to take me to the declaration.

Often the software house you're working for has installation standards which dictate you must use so-and-so convention for naming.
<<<

... and nothing has changed since.

I shall now quote DavidP's old sig: "A horse is a horse: there's no excuse for hungarian notation."

>>> A horse is a horse:

A Horse is a horse, a horse is a handle to an orse. :D

Quote:

---

Originally Posted by adrianxw

This is what I said the last we did this...

>>>
In all but a couple of special cases, I call my variable Variable or if two or more word SecondVariable, i.e. with each word capitalised. I shorten some words where this does not introduce ambiguity.

Exceptions are loop counters, I always start with a lower case i, then j, and so on - hang over from many years of coding in Fortran. Pointers I call pSomething, hang over from an early database system I used whereby that was a requirement, and for some reason, I call handles hSomething.

Functions follow the same rule as variables.

With todays IDE's, Hungarian is a relic, if I have forgotten what type a variable is, I put my cursor on it and the IDE tells me and offers to take me to the declaration.

Often the software house you're working for has installation standards which dictate you must use so-and-so convention for naming.
<<<

... and nothing has changed since.

---

I wish we had one of those "I'm not worthy" smilies on this board from Wayne's World. I'd totally whip it out right now.

I use the same exact notation. ThisIsTheNameOfMyVariablesAndFunctions, szNotThis

There is two versions of hungarian notation, one espoused by Charles Simonyi and one espoused by Charles Petzold.

I use both, but whatever you think of Petzold hungarian Simonyi hungarian is very useful.
The variable prefix shouldn't so much declare the type as declare the purpose.

Code:

---

1. void send(char * szData, size_t cchData)
2. void send(char * szData, size_t cbData)

---

cchData immediately tells me that cchData wants the length in characters of szData.
cbData immediately tells me that cbData wants the length in bytes of szData.
szData tells me that the data must be a null terminated string(rather than a byte array). These distinctions can not be made by the IDE and one would need to look up the documentation.

Code:

---

PrintWidgets(widget pWidgets[], size_t cWidgets)

---

Similarly, cWidgets makes it obvious that this argument expects a count of widgets.

See more here.

In fact, if apis were designed consistently with this sort of approach, they could be easier to use. How many times have you had to look up whether the number expected by the rather uselessly notated nSize or just length, size, etc expects bytes or characters(only windows seems to have picked up unicode in a big way, so this may not be a good example for non-windows programmers)?

Or one could simply use more apt naming conventions. i.e. What is wrong with:

Code:

---

1. void send(char * DataString, size_t DataChars)
2. void send(char * DataString, size_t DataBytes)

---

Everybody under the sun can tell you what is expected there.

I loathe the hungarian naming convention. I dont want to parse variable names for meaning. I just want to read it, and instantly know. Also far easier to keep track of names without having to look them up, IMO.

There is nothing wrong, put your notation as a suffix or a prefix, it doesn't make much difference. It is just that typically, you don't see DataChars, you see length or even n.

>> I loathe the hungarian naming convention. I dont want to parse variable names for meaning. I just want to read it, and instantly know. Also far easier to keep track of names without having to look them up, IMO. <<

Hungarian notation may not be the most readable naming convention and it is definitely not standardized among programmers but at least it is a naming convention.

Let's look at an example:

Code:

---

// Unix Opengroup - partial hungarian.
wchar_t *wcsncpy(wchar_t *ws1, const wchar_t *ws2, size_t n);

// Linux man - No hungarian
wchar_t *wcsncpy(wchar_t *dest, const wchar_t *src, size_t n);

// Suggested hungarian with 6 char limit.
wchar_t *wcsncpy(wchar_t * szDst, const wchar_t * szSrc, size_t cchDst);

---

Is [i]n[/n] the character count of ws1, ws2, or the byte count, maybe a count of the stars over the North Pole at 3:00pm on 14 January 1923?

The linux version is better than the opengroup version, but I think my version is clearer than both.

Sure you could use another clearer naming convention, but you actually have to use it.

Unfortunately, for my argument the lstrcpyn prototype is not much better than wcsncpy:

Code:

---

LPTSTR lstrcpyn(LPTSTR lpString1,  LPCTSTR lpString2,  int iMaxLength);

---

So, hopefully we can agree, whatever naming convention you decide on:
- It only works if you actually use it.
- It has to be used well.
- It is not a replacement for a variable name (as in ws1).

[edit]I'm not sure if I've made a case for using a notation or I've just made a case for actually naming your variables - n is not a name![/edit]

I prefer 14 year old aol girl notation

Code:

---

    int OMGLikeTotalyAnIntVariable = 0;
    int hI2uInTVaRiAble = 0;

---

Quote:

---

Originally Posted by XSquared

I shall now quote DavidP's old sig: "A horse is a horse: there's no need for hungarian notation."

---

This sig always brought a smile to my face. But I thought it was: there is no excuse for hungarian notation.

I also use something similar to Adrianxw's convention. For example, p in front of pointers.

>I prefer 14 year old aol girl notation
Good one! :)

You're right about that quote, swoopy. *fixed*

Indeed!

A horse is a horse (and a duck is a duck! but that was never in my sig). There is no excuse for Hungarian notation.

A horse is a badly capitalized HANDLE to an Orse ( whatever that may be ) :rolleyes:

I prefer hungarian in my C++ projects simply because it's one consistent style of naming things. Especially when interfacing with the MFC or other windows developers it's a pain to use different coding styles depending on which part of the project it is.

In C# projects I prefer these guidelines.

Quote:

---

Originally Posted by dbgt goten

I prefer 14 year old aol girl notation

Code:

---

      int OMGLikeTotalyAnIntVariable = 0;
      int hI2uInTVaRiAble = 0;

---

---

Code:

---

int lolHugglesluvya = 0;

---

Or the 1337 notation

Code:

---

#define 7|-|15\/4r14b130\|/|\|zj00 "15"

---

gotta love homestar notation

Code:

---

char ThisIsTotallyAVariableSeriously = 'f';

---

gotta love strongbad notation

Code:

---

float *CrapfacedVariableForATheCheat = &UntranslatableCheatSounds;

---

gotta love Ozzy notation

Code:

---

volatile englishman Ozzy = "adslgihsofghnsrohiaodsihgosirhngorhingoeaihr";

---

Of course, that may be more understandable than ozzy.

I got more, but this is getting old now :p