Hungarian notation pros vs cons

  • Thread starter Thread starter Ronald S. Cook
  • Start date Start date
Ken Wilson said:
Pretty much.
Click to expand...

So where would you use an m?
I like the 'g' idea by the way.. The other part goes
this way.

Foo iRedFoo;
Foo iBluFoo;
Click to expand...

So that's where I'd use m_ - I'm confused about where you'd use an m.
We avoid underscores by using camel casing, or is it Pascal casing,
that always confuses me.
Click to expand...

It's sort of a mixture... PascalCasingStartsTheFirstWordCapitalised,
camelCasingStartsTheFirstWordLower.

In your case, the first *word* is capitalised, but the first letter of
the identifier itself is still lower case...
Luckily the boss doesn't care about that as long as I get it right.
He's more worried if I get confused actually writing code. ;-)
Click to expand...

:)
 
So where would you use an m?
Click to expand...

Where you have the 'm_' only without the underscore.

My boss' interpretation is each of those is an instance of Foo
therefore, 'i'.

If, for argument sake, a member variable happened to be public (makes
sign of cross and says quick prayer to the Gods of 1 and 0) we would
be able to do this.

iRedFoo.mDeveloperIQ = 0; // hehehe...

This is actually helpful inside methods where you have the usual mix
of method and class member variables. Although we have other clues
such as plain-old variables are camel-cased with no prefix I feel it
doesn't hurt to have the additional clue and it doesn't impact
productivity.
So that's where I'd use m_ - I'm confused about where you'd use an m.


It's sort of a mixture... PascalCasingStartsTheFirstWordCapitalised,
camelCasingStartsTheFirstWordLower.

In your case, the first *word* is capitalised, but the first letter of
the identifier itself is still lower case...


:)
Click to expand...

Ken Wilson
Seeking viable employment in Victoria, BC
 
Ken Wilson said:
Where you have the 'm_' only without the underscore.


My boss' interpretation is each of those is an instance of Foo
therefore, 'i'.
Click to expand...

So it's actually a difference between value types and reference types?
Ah - that's more like the broken Hungarian, and is awful IMO.
If, for argument sake, a member variable happened to be public (makes
sign of cross and says quick prayer to the Gods of 1 and 0) we would
be able to do this.

iRedFoo.mDeveloperIQ = 0; // hehehe...

This is actually helpful inside methods where you have the usual mix
of method and class member variables. Although we have other clues
such as plain-old variables are camel-cased with no prefix I feel it
doesn't hurt to have the additional clue and it doesn't impact
productivity.
Click to expand...

I can't see how having the i/m differentiation helps. You need to know
the type in order to use the variable anyway, and knowing the type
tells you whether it's a reference type or a value type.
 
So it's actually a difference between value types and reference types?
Ah - that's more like the broken Hungarian, and is awful IMO.


I can't see how having the i/m differentiation helps. You need to know
the type in order to use the variable anyway, and knowing the type
tells you whether it's a reference type or a value type.
Click to expand...

If it were up to me there wouldn't be any prefixing but a stronger
emphasis on meaningful names. I firmly believe if your starting to
get longer than a couple of hundred lines of code for anything smaller
than an actual class, i.e. a method, you really need to review the
design. That alone, IMO, will reduce the size of the headache and the
need for prefixes should be redundant. When I run my own company I'm
going to ... [8-)

Ken Wilson
Seeking viable employment in Victoria, BC
 
Ken Wilson said:
I can't see how having the i/m differentiation helps. You need to know
the type in order to use the variable anyway, and knowing the type
tells you whether it's a reference type or a value type.
Click to expand...

If it were up to me there wouldn't be any prefixing but a stronger
emphasis on meaningful names. I firmly believe if your starting to
get longer than a couple of hundred lines of code for anything smaller
than an actual class, i.e. a method, you really need to review the
design. That alone, IMO, will reduce the size of the headache and the
need for prefixes should be redundant. When I run my own company I'm
going to ... [8-)
Click to expand...

Couple of hundred lines of code? I get worried if I can't fit a method
in one screen...
 
Back
Top