Has Microsoft recommended dropping Hungarian notation for .NET development?

  • Thread starter Thread starter BillyTheKid
  • Start date Start date
B

BillyTheKid

I've heard from various sources that Microsoft recommends dropping Hungarian
notation for .NET development but am unable to explicitly find this
recommendation or their reasons for doing so. Does anyone know if it is
true... or merely urban myth?
 
Billy,
Yes they have dropped it.

For the new recommendations see:
http://msdn.microsoft.com/library/d...ef/html/cpconNETFrameworkDesignGuidelines.asp

http://msdn.microsoft.com/library/d...ef/html/cpconNETFrameworkDesignGuidelines.asp

For private fields, I will use Hungarian on control names. Seeing as they
are private this doesn't really matter.

I don't have a reference to why, however it has been rehashed in the
microsoft.public.dotnet newsgroups enough that searching
http://groups.google.com should turn up something.

Hope this helps
Jay
 
I see that it isn't in there, but it is not explicity called out as to why.
Perhaps it would be helpful to the debate if Microsoft took a more
definitive stance and explained thier reasonong.
 
Billy,
Like I said this has hashed & rehashed and turned upside down, sliced,
diced, purée, minced, mashed, ... Till the cows came home and got feed up
and left ;-)

If you need debate material, search the microsoft.public.dotnet newsgroups
at http://groups.google.com should turn up enough why.

There may actually be articles on MSDN as to the why, I just do not have
links handy. I get this vague idea that Dr Gui and or MSDN Magazine covered
the why on different occasions.

Hope this helps
Jay
 
MSFT has added capabilities so you can see the data type, etc., but real
programmers know that it is often necessary to print out code and look at
the code away from a terminal.
Click to expand...

I'm surprised that you say that. I can't remember the last time I printed
out code for any reason, let alone to look at it away from the m/c.

Do people still do that?

Charles
 
Yes, but it makes no sense to do so.

MSFT has added capabilities so you can see the data type, etc., but real
programmers know that it is often necessary to print out code and look at
the code away from a terminal.
 
The real problem I have with it is that over time as the code needs to
change you might end up with a var name like intNumber actually being a long
type.

Changing var names is a pain...

Working with ones that have not been changed but need to be is even worse.
 
Howard Kaikow said:
Yes, but it makes no sense to do so.

MSFT has added capabilities so you can see the data type, etc., but real
programmers know that it is often necessary to print out code and look at
the code away from a terminal.
Click to expand...

I agree with Charles on this - how often do you actually do that?
 
Howard Kaikow said:
Yes, but it makes no sense to do so.

MSFT has added capabilities so you can see the data type, etc., but real
programmers know that it is often necessary to print out code and look at
the code away from a terminal.
Click to expand...


The last time since I remember commercial programming I have printed code
out only occasionally to grasp some complex algo (and hungarian would not
have helped there), And I have only printed larger parts ONCE - to but them
into a binder and present them to a customer as "offical code turnover
event".

I have never really considered looking at code outside of the IDE somethign
"real programmers" do.

--
Regards

Thomas Tomiczek
THONA Software & Consulting Ltd.
(Microsoft MVP C#/.NET)
 
Howard Kaikow said:
Often.
Click to expand...

Why, out of interest? It does sound (given the other responses here) as
if you're in the minority here - and conventions can always be tweaked
if you're in special circumstances (such as being in a position where
you often need to do something that other people only do very rarely).
 
What's wrong with performing them via an IDE? Quite a bit more convenient,
particularly wrt to tracking down dependencies, than printed code...
 
Billy,
Unless you are running a "Code Critic", yes!

How else do you enforce adherence to standards & maintain a certain
consistency in your teams code?

Also, I view code reviews as an opportunity for both the reviewer & the
developer to learn about new techniques.

Hope this helps
Jay
 
Back
Top