Jag tycker det är oldschool och inte hör hemma i .NET, ok vill alla köra på det så är det ok bara det är konsekvent, men jag hade inte velat arbeta med det.
Här under kommer ett citat ur av chefsarkitekten av .NET från en av mina favoritböcker "Framework Design Guidelines"
Expert from 3.2.5 Word Choice
DO NOT use Hungarian notation.
KRZYSZTOF CWALINA There have always been both positive and negative
effects of using the Hungarian naming convention and they still exist
today. Positives include better readability (if used correctly). Negatives
include cost of maintenance, confusion if maintenance was not done properly,
and finally, Hungarian makes the API more cryptic (less approachable)
to some developers. In the world of procedural languages (e.g., C) and the
separation of the System APIs for advanced developers from framework
libraries for a much wider developer group, the positives seemed to be
greater than the negatives. Today, with System APIs designed to be
approachable to more developers, and with object-oriented languages, the
trade-off seems to be pulling in the other direction. OO encapsulation
brings variable declaration and usage points closer together, OO style
favors short, well-factored methods, and abstractions often make the exact
type less important or even meaningless.
Länkkälla: http://blogs.msdn.com/brada/archive/2005/11/04/486216.aspx
Hämtat ur wiki (nu tog jag visserligen inte med fördelarna, men de flesta fördelarna kan man få med om man döper sina variabler med bra namn. Samt använder intellisensen.
Critics argue that:
* The Hungarian notation is redundant with the type checking made by the compiler. A language providing type checking will be much more powerful to ensure that the usage of a variable is consistent with its type than the human eye would be to merely check that usage is coherent with the name of the variable.
* Some modern Integrated development environments, such as Visual Studio display variable types on demand, and automatically flag operations which use incompatible types[citation needed], making the notation largely obsolete.
* Hungarian Notation becomes confusing when it is used to represent several properties, as in a_crszkvc30LastNameCol: a constant reference argument, holding the contents of a database column LastName of type varchar(30) which is part of the table's primary key.
* It may lead to inconsistency when code is modified. If a variable's type is changed, either the decoration on the name of the variable will be inconsistent with the new type, or the variable's name must be changed.
* It is inconsistent with code portability since the variable name is tied to the type. A particularly well known example is the standard WPARAM type, and the accompanying wParam formal parameter in many Windows system function declarations. It was originally a 16 bit type, but was changed to a 32 bit or 64 bit type in later versions of the operating system while retaining its original name (its true underlying type is UINT_PTR, that is, an unsigned integer large enough to hold a pointer).
* Most of the time, knowing the use of a variable implies knowing its type. Furthermore, if you don't know what a variable is used for, knowing its type won't help you.
The .NET Framework, Microsoft's new software development platform, generally does not use Hungarian notation except in the case of interface types. In .NET the convention is to place I before the name of interface types (for example, the IButtonControl interface in Windows Forms.) The .NET Framework Guidelines advise programmers that Hungarian notation should not be used, but does not specify whether to avoid Systems Hungarian, Apps Hungarian, or both.[2] In contrast, the standard libraries of the Java programming language do not prefix interface types.[3]
Länkkälla: http://en.wikipedia.org/wiki/Hungarian_notation
