"It's for backwards compatibility"

Pages: 123
Hungarian notation?


To identify the type of a variable, the variable name would start with the letter(s) of its type. So a variable sum of type double would be dsum, a variable of name of type char* would be lpchar (long pointer - don't ask unless you did 16 bit programming...). A handle variable would start with h etc etc. Microsoft were very hot on this way back when. I never liked it.
There are two different types of Hungarian notation: Systems Hungarian and Apps Hungarian.

The former encodes a variable name with the actual data type. The latter encodes the logical data type, giving a hint as what the variable's purpose is.

It can be argued Apps Hungarian is marginally more useful than Systems Hungarian. SH is just painting the lily.

https://duckduckgo.com/?q=what+is+hungarian+notation&t=ffsb&ia=web

I do on occasion use some light form of notation to denote global variables and class data members and the like, though the curve is bending downwards to non-use as time goes on.
That actually sounds kind of handy, if you have a bunch of code and don't want to go back and see what type of variable something is.

I use TextMate for writing code, so I don't have all the fancy stuff that you get with an IDE. I actually sometimes do that with function variables, so I'll have something like:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
int main ()
{
      double num {};
      char letter {};
      
      // ...
      
      int amount {};
      
      amount = function (num, letter);
      
      return 0;
}

int function (double in_num, char in_letter)
{
      int out_num {};
      
      // ...
      
      return out_num;
}

It just makes it easier to tell stuff apart. If you're like me and don't have an IDE.
The type of notations I use on occasions:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
#include <iostream>

class Foo
{
public:
   int m_bar { 25 };
};

int g_bar { 100 };

int main()
{
   Foo foo;

   int bar { };

   std::cout << bar << ' ' << foo.m_bar << ' ' << g_bar << '\n';
}
The latter encodes the logical data type, giving a hint as what the variable's purpose is.
Arguably, that's what the name is for.
The trouble with Hungarian Notation is when it gets out of hand - it's not obvious what the notation means. I have seen examples where there were 4 capitalised chars at the beginning of a class name - no idea what that means unless it's documented somewhere.

I tend to put "global" variables into their own namespace.

For in/out parameters there are sections F.16 to F.20 in coreguidelines.

https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rf-in

Note they don't have an in/out naming convention.
Hungarian Notation - or in general, using names that carry type information - may be useful in untyped languages.

Embedding semantic information in names is occasionally useful in languages like C++: for example, if temperatures are sometimes in Celsius and sometimes in Fahrenheit, it may make sense to have a uniform naming convention. For example, cAmbientTemp vs fAmbientTemp


> Arguably, that's what the name is for.

The Hungarian Notation is a naming convention.
Hungarian notation, popularised by the Windows SDK, precursor to camel-case ... you either love it or hate it:
 
lpcszTitle
Last edited on
Definitely now one of my hates - and for a long time! Although it was sort of useful if not taken to extreme way, way back when Ide's editors were just that - basic text editors.
The Hungarian Notation is a naming convention.
*Arguably, that's what the non-wart part of the name is for.
In other words, if you start to encode the meaning of the data the variable holds in the wart, then what do you use the rest of the identifier for?
Hungarian Notation, especially Systems Hungarian, was definitely used and abused well beyond the scope of usefulness.

In SH the notation would encode the data type. szName ("sz" for zero-terminated string) or iCount for a counting integer.

Apps Hungarian encoded what a variable represented. usName ("us" for unsafe string that required processing to be usable) or rwPosition ("rw" represents row).

Add in the mash-up of Windows data types and it really can be a migraine-inducing experience.

What exactly is an LPTSTR? Or an HWND?

MS added, changed and deprecated some data types for 64-bit, just as they did for 32-bit. 16-bit Windows is dead.

The latest craze for Desktop Windows programming is SAL.
https://docs.microsoft.com/en-us/cpp/code-quality/using-sal-annotations-to-reduce-c-cpp-code-defects?view=msvc-160
SAL. Which committee came up with that?
The trouble with Hungarian Notation is

the trouble I have with it is that for the last 20 or so years most IDE tell you the type in a mouse-over. It had merits back when, but its obsolete now, IMHO.
JLBorges wrote:
For example, cAmbientTemp vs fAmbientTemp

Yeah, I do that all the time. My text editor– TextMate– allows me to type the first couple letters of a variable, then hit the ESC key and it automatically completes the variable name. Which has led to some bad habits with using overly long, complicated names.

jonnin wrote:
but its obsolete now, IMHO

I still sort of use it, because I don't use an IDE. I won't go into why, it's a long explanation, but the short one is, I've used TextMate for almost 20 years now, I'm used to it, and I don't want to learn something else. I also hate how IDE's are always so complicated, and they have unnecessary stuff like a debugger and compiler, both of which I already have (clang++ or g++ and lldb or gdb).

[Edit] Misattributed first quote to @TheIdeasMan, quote was actually from JLBorges.
Last edited on
@agent max

That quote was from JLBorges, not me :+)
Whoops! Sorry! Have I done that before? I seem to remember something like this happening a while back. Maybe it was someone else.
Topic archived. No new replies allowed.
Pages: 123