Why NOT hungarian notation?

[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_emailAddres s
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

--
=============== =============== =============== =============== =====
Win prizes searching google:
http://www.blingo.com/friends?ref=hM...nTqhv-2GE1FNtA

[Joerg Jooss]

Thus wrote Joerg,

Thus wrote Mark,

>"darrel" <no*****@nowher e.comwrote in message
news:eC******* ******@TK2MSFTN GP06.phx.gbl...

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

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)

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

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.

Of course this only applies if you miss renaming variables when implementing
the type change or decide to update your type prefixes throughout.

Cheers,
--
Joerg Jooss
ne********@joer gjooss.de

[Mark Rae]

"Joerg Jooss" <ne********@joe rgjooss.dewrote in message
news:94******** *************** ***@msnews.micr osoft.com...

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.

"All over the place..."??? With a properly designed system, this should
hardly ever happen anyway i.e. your database field types, class properties
etc should already be agreed upon before you start writing your first line
of code. If that isn't the case, then that *really* is stupid...

Accordingly, changing a variable name because of a type change is not only
stupid but also expensive, IMNSHO.

Not nearly so stupid and expensive as having to refer constantly to
IntelliSense, or the technical spec, every time you need to know what
datatype a variable or class property is...

Being a jobbing IT consultant, I'm quite often brought in to fix or update a
system where there is no documentation, and I always charge extra if the
code doesn't use Hungarian notation or, at least, *some* sort of notation
because, without it, it will take me proportionately longer to do my work.

E.g. imagine a Customer class with a CustomerID property - what datatype is
CustomerID?

[Registered User]

On Sat, 9 Dec 2006 11:02:10 -0000, "Mark Rae" <ma**@markNOSPA Mrae.com>
wrote:

>
E.g. imagine a Customer class with a CustomerID property - what datatype is
CustomerID?

I dunno it might be a value type instead. Once I find out I won't need
to be constantly reminded that CustomerID is a string or an int or
even an object of type CustomerID. I find this ability especially
helpful when working with generics.

The question itself reads as if you are suggesting being consistant
and using hungarian notation in every scope. I agree, if hungarian
notation is to be used at all, it should be used everywhere so all
consumers can receive all the supposed benefits.

public class Customer
{
// public int int_CustomerID {...}
// public string str_CustomerID {...}
public CustomerID custid_Customer ID {...}
public string str_CustomerNam e {...}
...
}

regards
A.G.

[Mark Rae]

"Registered User" <n4***@ix.netco m.comwrote in message
news:o9******** *************** *********@4ax.c om...

>>E.g. imagine a Customer class with a CustomerID property - what datatype
is
CustomerID?

I dunno

Of course you don't...How could you...?

it might be a value type instead.

Instead of what...?

Once I find out I won't need to be constantly reminded that CustomerID is
a
string or an int or even an object of type CustomerID.

LOL! Well, if you have a photographic memory, I certainly don't! Yes, once I
know it's an int or whatever, I'll retain that particular piece of
information for as long as I need to. But next week, next month, next year
when I come to revisit the code in response to a request for change or
whatever, I'll almost certainly have forgotten it again...

I find this ability especially helpful when working with generics.

Me too.

The question itself reads as if you are suggesting being consistant
and using hungarian notation in every scope.

I most certainly am.

I agree, if hungarian notation is to be used at all, it should be used
everywhere so all consumers can receive all the supposed benefits.

I couldn't agree more!

[Registered User]

On Sat, 9 Dec 2006 13:28:07 -0000, "Mark Rae" <ma**@markNOSPA Mrae.com>
wrote:

>"Registered User" <n4***@ix.netco m.comwrote in message
news:o9******* *************** **********@4ax. com...

>>>E.g. imagine a Customer class with a CustomerID property - what datatype
is
CustomerID ?

I dunno

Of course you don't...How could you...?

>it might be a value type instead.

Instead of what...?

Instead of a nullable datatype.

>

>Once I find out I won't need to be constantly reminded that CustomerID is
a
string or an int or even an object of type CustomerID.

LOL! Well, if you have a photographic memory, I certainly don't! Yes, once I
know it's an int or whatever, I'll retain that particular piece of
information for as long as I need to. But next week, next month, next year
when I come to revisit the code in response to a request for change or
whatever, I'll almost certainly have forgotten it again...

Myself as well but the time frame can be shorter. It never hurts to
review the code your going to touch. Part of the review is to refresh
the understanding of the existing design and code. The balance is to
consider and understand what changes are required and how those should
be accomplished. If this isn't done the programmer is just hacking on
the code trying to make 'it' (the desired changes) work.

>I find this ability especially helpful when working with generics.

Me too.

It doesn't take much to make CustomerID a generic.
public Customer<Custom erID>
{
public CustomerID CustomerID{...}
...
}
If this isn't riddle then this should be either
public Customer<Custom erID>
{
public int CustomerID{...}
...
}

>The question itself reads as if you are suggesting being consistant
and using hungarian notation in every scope.

I most certainly am.

>I agree, if hungarian notation is to be used at all, it should be used
everywhere so all consumers can receive all the supposed benefits.

I couldn't agree more!

I was trying to be tongue-in-cheek, not foot-in-mouth. My problem with
hungarian notation is it has never been used to describe public
properties that point to hungarian-notated private and protected
members. This inconsistancy and the fact there is no standard makes me
question the value of the whole process especially in this day and
age.

If hungarian notation works for you that is fine and dandy. We can
agree to disagree. Now step away from the computer and take the rest
of the day off. That is what I'm doing.

regards
A.G.