Do I always have to write "self." ?

[Samuel A. Falvo II]

In article <8ehrb9$mm5$1 at ites.inria.fr>, Cedric Adjih wrote:
>  If you can read, you should be able to read the definition of 
>any variable, and there are serious drawbacks. A flame of this
>notation is for instance in "Developing Windows NT Device Drivers":
>"The so-called `Hungarian Notation' (developped by a Hungarian
>programmer at Microsoft) is one of the worst ideas to have hit
>software development in many years"

"All good ideas are judged from the enemies they make." -- I forgot who.

>  The main problem, is that when you change the type of a structure
>you _cannot_ change the name (because other people are using it),
>so the type specification becomes plain wrong. The 'wParam'
>is reported to be such an example (now unsigned 32 bits), there
>are other examples in Microsoft API (should be worse with Win64).

Hungarian notation is fine for the definition of an API, as long as its used
to describe abstract concepts, like arrays, pointers to things, a count of
whatever, etc.  Hardcoding the bit-widths of types is obviously going to get
you into trouble in the future.  Just because Microsoft fscked up the
execution doesn't mean the idea is somehow "bad."

Like I said earlier, I use it only when it makes *sense* to.  Like anything
else you have in your toolshed, Hungarian notation is a tool.  Those who are
skilled in its use will not have the problems you cite above.  :)  Those who
aren't only use it because it's a fad.

>  Also each time you change the type of one variable/parameter, 
>you have change all the variable names of all the code under
>your control.

In my work with Dolphin, I've found, on several occasions, where I needed to
change symbol names pervasively throughout the source.  I have found #MORE
BUGS# just waiting to crop up and bite me in the butt this way than through
any other technique.  The very thing you cite as a "problem" is the very
thing that will help reduce the number of bugs in Dolphin upon its final
release.  Is it painful?  You bet.  Just ask Billy -- the translation from
old symbol names to new names broke the compile for weeks.  But once it was
all over, I had fixed no less than 14 bugs that would *never* become
apparent until after I'd released the code to the public.  Most of the bugs
were bound to be of the "intermittent" type too, so I was particularly
pleased at the end result.

I view it as sheer laziness on the programmers part.  You get what you pay
for.

>  And finally, for multi-platform code, it makes less sense:
>what happens if you don't have 2-bytes integers and you
>have code with wXXXX variables (unsigned int 16 bits) ?

On PowerPCs, a word is 32-bits.  On Intels, 16-bits.  So what's the lesson
to be learned here?  Don't hardcode widths in the meanings of your symbols.

Hungarian notation as used by Microsoft is by far NOT the only way to use
it.  For example, I *never* identify word-widths in my Hungarian notated
variable names.  Why?  Because of the very problem you cite above.  However,
I do indicate higher-level meanings with prefixes: p for pointer, c for a
count (e.g., cb for a count of bytes, cuint32 for a count of 32-bit unsigned
integers, etc), a for array, etc.

Again, it takes skill to use a tool well.

-- 
KC5TJA/6, DM13, QRP-L #1447
Samuel A. Falvo II
Oceanside, CA