Why NOT hungarian notation?

  • Thread starter Thread starter darrel
  • Start date Start date
D

darrel

I just discovered that MS recommends that we NOT use hungarian notation with
the .net framework:

http://msdn2.microsoft.com/en-us/library/ms229045.aspx

What are the real cons for using it?

I tend to use it a lot, especially when IDing my controls. For instance the
controls in a contact form I create could be IDed as such:

tbx_firstName
tbx_emailAddress
ddl_state

I find this really helpful when in codebehind.

is the 'no hungarian' merely a preference MS has, or are there specific cons
to me being stubborn and sticking with it?

-Darrel
 
I just discovered that MS recommends that we NOT use hungarian notation
with the .net framework:

http://msdn2.microsoft.com/en-us/library/ms229045.aspx
Click to expand...

Weird, isn't it! It was all the rage for years, then suddenly they don't
like it any more...
What are the real cons for using it?
Click to expand...

None whatever.
I tend to use it a lot, especially when IDing my controls.
Click to expand...

Me too - all the time.
I find this really helpful when in codebehind.
Likewise.

is the 'no hungarian' merely a preference MS has,
Click to expand...

I have no idea...
or are there specific cons to me being stubborn and sticking with it?
Click to expand...

None whatever.
 
or are there specific cons to me being stubborn and sticking with it?
None whatever.
Click to expand...

Ha! Thanks for the feedback, Mark. At least I can find peace with me knowing
that I'm not alone in wanting to stick with it. ;o)

-Darrel
 
The biggest argument against hungarian notation is that it makes it harder
to refactor code. People argue that it's violates the Don't Repeat Yourself
(DRY) principle. Personally, I think that's a little much, but the side
effect IS the same. If you change the type of your variable, you now need to
change all instances of that variable.

if you have rptBooks and want to change it to a datagrid, you now have to
refactor your name or risk having hard code to maintain.

With the advances in IDEs generally and intellisense specifically, the
question is what value does hungarian notation offer?

I'd be interested in taking a look at a codebehind page you feel it ads
value.

Karl
 
Ha! Thanks for the feedback, Mark. At least I can find peace with me
knowing that I'm not alone in wanting to stick with it. ;o)
Click to expand...

Without doubt the stupidest reason for not using it I've ever come across
was that you might change the underlying datatype (e.g. from byte to
integer) that a variable referred to, so you'd have to go through your
entire code and change it...

Well, my copy of VS.NET has got a find and replace utility...
 
If you change the type of your variable, you now need to change all
instances of that variable.
Click to expand...

Personally, I would use Find / Replace for such a task - wouldn't you...?
 
I just discovered that MS recommends that we NOT use hungarian notation with
the .net framework:

http://msdn2.microsoft.com/en-us/library/ms229045.aspx

What are the real cons for using it?
Click to expand...
Nothing although the various 'dialects' can be confusing and
internally inconsistent.
I tend to use it a lot, especially when IDing my controls. For instance the
controls in a contact form I create could be IDed as such:

tbx_firstName
tbx_emailAddress
ddl_state

I find this really helpful when in codebehind.
Click to expand...
My preference is to be verbose as needed to make the code easier to
read. A few extra key strokes for clarity can go a long a way i.e.
firstNameTextBox or firstNameEdit.
is the 'no hungarian' merely a preference MS has, or are there specific cons
to me being stubborn and sticking with it?
Click to expand...
You may run into situations where corporate/department/office policy
does not appreciate hungarian notation as much as you do. For all
practical purposes IntelliSense and similar tools make hungarian
notation obsolete.

regards
A.G.
 
Hi,

Registered said:
You may run into situations where corporate/department/office policy
does not appreciate hungarian notation as much as you do. For all
practical purposes IntelliSense and similar tools make hungarian
notation obsolete.

regards
A.G.
Click to expand...

Very much in the contrary IMHO. I tend to forget how my variables are
named, especially which letter they start with, but I do not forget
which type they have. If I want a string, I type "str" and all the
strings are nicely grouped in Intellisense. If anything, Intellisense
makes hungarian notation even more useful!!

HTH,
Laurent
 
Very much in the contrary IMHO. I tend to forget how my variables are
named, especially which letter they start with, but I do not forget which
type they have. If I want a string, I type "str" and all the strings are
nicely grouped in Intellisense. If anything, Intellisense makes hungarian
notation even more useful!!
Click to expand...

Tout à fait d'accord avec toi, mon pote!

Which is to say that I agree entirely with Laurent.

Hungarian notation makes it easier for me to write my applications - if I
didn't use it, it would make it more difficult for me to write my
applications.

I think the OP would also agree with the above...
 
If anything, Intellisense makes hungarian notation even more useful!!

Excellent point!

-Darrel
 
With the advances in IDEs generally and intellisense specifically, the
question is what value does hungarian notation offer?
Click to expand...

So true! Especially as VS 2005 has very good refactoring that kicks in when
you rename a variable!
 
no.

find/replacing is dangerous. What happens if you use that same name
somewhere else but don't change its type?

I use JetBrains Resharper which provides much better refactoring than VS.NET
2005. It would do it for me. So that's a case against my own argument :)

Karl
 
Very much in the contrary IMHO. I tend to forget how my variables are
named,
Click to expand...

I would suggest using a more meaningful naming convention but I just
can't fathom the situation you describe.

regards
A.G.
 
find/replacing is dangerous. What happens if you use that same name
somewhere else but don't change its type?
Click to expand...

Then I would correct it on the unlikely event that that would occur...

Also, I wouldn't just blithely hit "Replace all"...
I use JetBrains Resharper which provides much better refactoring than
VS.NET 2005. It would do it for me. So that's a case against my own
argument :)
Click to expand...

LOL! Well there you go!
 
I do use o for local objects, mo for class or module level and go for global
objects. Hungarian Notation rocks and after using it for the last 15 years I've
yet to see a good reason not to.
 
That is a very good article. I wish I had known about Apps Hungarian because
apparently I am an abuser of Apps System where the type is a small part of the
variable naming convention rather than the "kind" of thing it is.

When I see code that does not use Hungarian notation I feel like half my brain
is turned off and I then have to work twice as hard to stay in the same place.
Joel does an excellent job of explaining why and where that perception comes
from.

Thanks for a great perspective.
 
Thus wrote Mark,
Without doubt the stupidest reason for not using it I've ever come
across was that you might change the underlying datatype (e.g. from
byte to integer) that a variable referred to, so you'd have to go
through your entire code and change it...

Well, my copy of VS.NET has got a find and replace utility...
Click to expand...

Unfortunately, changing source code all over the place usually means going
through the entire test cycle of that component *again*, even though semantically
there's no change. Accordingly, changing a variable name because of a type
change is not only stupid but also expensive, IMNSHO.

Cheers.
 
Back
Top