Why NOT hungarian notation?

[Joerg Jooss]

Thus wrote Joerg,

Thus wrote Mark,

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,

 

[Mark Rae]

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]

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_CustomerID {...}
public string str_CustomerName {...}
...
}

regards
A.G.

 

[Mark Rae]

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]

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


Instead of what...?

Instead of a nullable datatype.

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.

Me too.

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

I most certainly am.


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.