Do I always have to write "self." ?

[Cedric Adjih]

Samuel A. Falvo II <kc5tja at garnet.armored.net> wrote:
> 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.

  It's ok. It's just that most of the time I've read some code using it,
it was following Microsoft broken conventions. I personally don't
like marking pointers/arrays (he! that would be like Perl), but I
using it in a clever way, is of course quite good.

>>  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.

  That's right. This is why, when I change code and break some
invariant/expectation (even if the types aren't changed), I often
change the variable/struct/function names, to review all the code
possibly using it.

>>  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. 

No but the very name "Hungarian notation" comes from its (incorrect) use
at Microsoft.

>     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.

Agreed.

-- Cedric