Why not using Hungarian Notation

Definition:

Hungarian Notation (HN) is a naming convention invented by Charles Simonyi from Microsoft. In HN one writes things like m_nSize, hwndParent and lpszFile.

Advantages:

Hungarian notation (or a variation of this) has its place in Languages when referring to data that really DOES have a particular type.

Handles can have a 'h' prefix (eg hWnd) - this is simply a shorthand convention that save writing something like 'handle_of_Window'. Similarly 'nLines' is short for 'number_of_lines', 'bOpen' is short for 'is_open', 'pData' is short for 'pointer_to_data'.

As a convenient (and hopefully consistently used) shorthand, such a notation can save on extra typing - and less typing can mean less typing mistakes and more compact (but just as readable) code.

Hungarian notation works perfectly in naming asp.net Controls since each of the control has its particular “type” e.g. a “textbox” control can be named “txt_username”, a list view control can be named “listview_shoppingCarts” etc..

Disadvantages:

Hungarian notation does not have it place in the OOP language code at all. Since it brings variable type in the the naming, it literally violates polymorphism. In OOP, a variable or a parameter can have different types, naming the variable with a single type becomes un-logical and less convenience.

case 1: when an variable changes, we must search through the entire project to rename the variable.

case 2: If you have a type for a host variable, the proper way to name it is to use something like HostID. Then anyone can declare a variable to be of type HostID and use its operations without knowing or caring if it is a class, a structure, an integer, etc.. Notice that the HostID can be of any type and you don't care or want to know what type it is. You only need to know that it is the type required for a parameter to a function or what operations are available on the type.

Suggestions:

Usually, variables, fields, and parameters should be declared using the following template: Adjective(s) + Noun + Qualifier(s).

Examples:

int lowestCommonDenominator = 10;
float firstRedBallPrice = 25.0f;

Guidelines:

· Use Camel casing when naming variables, fields, and parameters.

· Always use descriptive variable, field, and parameter names.

· Always use names based on a parameter’s meaning, rather than its content type.

· Define variables as close as possible to the first line of code where they are used.

· Declare each variable and field on a separate line. This allows the use of End-of-Line comments for documenting their purpose.

· Assign initial values whenever possible. The .NET runtime defaults all unassigned variables to 0 or nullautomatically, but assigning them proper values will alleviate unnecessary checks for proper assignment elsewhere in code.

· Avoid meaningless names like i, j, k, and temp. Take the time to describe what the object really is (e.g. use index instead of i; use swapInt instead of tempInt).

· Use a positive connotation for Boolean variable names (e.g. isOpen as opposed to notOpen).

· Do not add a prefix to field names. For example, do not prefix “m_” to member variables, “g_” to global variables, and “s_” to static variables.

· When declaring a variable for use within an iterative loop (foreach, while, etc), declare the variable before the loop is entered. This will save memory from being allocated to store the variable each time the code is looped through, providing significant performance improvements to your code.

转载于:https://www.cnblogs.com/lochker/archive/2011/08/04/2126856.html