EntBlog
Code, 3D, Games, Linux and much more...

With all the evangelising done by Microsoft Press, I find myself using Hungarian notation systematically at work, both to denote scope and typing, as well as some semantic information such as the format of a string. However, I personally find this practice a convoluted workaround for the shortcomings of some compilers (and sometimes the C++ language itself), in particular for type denomination; actually, most recent compilers provide adequate warnings for the implicit promotion of arithmetic types, and singed/unsigned operations (comparisons, shifts, etc). As for character and string types (acz, sz, autf16z, wtf…) it seems like a lack of good conventions. Also, the nature of variables of constructed types like arrays and pointers should be given by the context, and not by the name, as there are much more subtle details (ownership, persistence) that require a deeper understanding of the code by the programmer and Hungarian notation does not cover.

With regard to scope naming conventions, I think C++ actually needs them, since the compiler cannot possibly report most of the semantic errors that the misuse of these variables may lead to. Perhaps the syntax could be changed as to make the programmer more aware (e.g. removing the ellipsis of “this->” in member functions) but this would be also quite cumbersome. Anyway, still lot of room for improvement for programming languages… something we should be happy about, isn’t it?

My 2p

Manolete

Comment by Manolete
April 5, 2006 @ 2:30 #

Microsoft doesn’t recommend Hungarian notation anymore, of that is what I think. I think that a strict Hungarian notation is bad but a light hungarian notation may be useful for C++.

Hungarian notation for scope is really useful, adding a m_ to member variables is not only useful to indicate that you are using a member variable but to avoid name conflicts in the typical Get/Set function. If someone admits scope information in the variable names, following the same reasoning type information should be accepted too (at least, a simple one). Simple type information like an i_ for integer, ui for unsigned, sz for char* and f_ for floats can give you extra information that sometimes you cannot easily get from the context (and that you could get from Intellisense or VisualAssist but most of the times this won’t work).

For example, reading this code (under a code review):

val = a + b - c - d;

This expression may get your attention depending of the types involved (integers or floats). For example, if they are floats you must be sure that a, b, c and d are sorted properly to get the maximum precision in the operation.

Yesterday I was thinking in leaving this notation and now I am convinced that it is still really useful. I only have to relax the rulex a bit.

Comment by ent
April 5, 2006 @ 3:45 #

I definitely agree ent. m_ is really useful for C++. And I’ve never liked this notation to give information about a variable type (f_ , i_, bla, bla). Some time ago, when development tools weren’t too advance, well I could understand using it but, nowadays, it doesn’t make any sense for me. Just an example, if you are using Visual Studio 2005, the code editor gives you a bunch of information about a variable just moving the cursor over it. And I know there were some addons that did the same on older version of Visual Studio. There is no need for redundancy.

PS: ent, did you finish reading “Conceptual Blockbusting”?

Comment by Alberto
April 6, 2006 @ 0:58 #

Yes, I finished it. I wrote a little review.

Comment by ent
April 11, 2006 @ 3:05 #