What Is a Hungarian Notation?

Hungarian nomenclature is a naming convention when programming. The basic principle is: variable name = attribute + type + object description, where the name of each object must have a clear meaning, you can take the full name of the object or part of the name. Be based on principles that are easy to remember and understand. It's important to keep the name consistent.

Hungarian nomenclature

Properties section :

g_

hwnd: h is a type description, representing a handle, wnd is a variable object description, representing a window, so hwnd represents

Naming conventions for MFC, handles, controls, and structures:

Windows type sample variables; MFC class sample variables

HWND hWnd; CWnd * pWnd;

HDLG hDlg; CDialog * pDlg;

HDC hDC; CDC * pDC;

HGDIOBJ hGdiObj; CGdiObject * pGdiObj;

HPEN hPen; CPen * pPen;

HBRUSH hBrush; CBrush * pBrush;

HFONT hFont; CFont * pFont;

HBITMAP hBitmap; CBitmap * pBitmap;

HPALETTE hPaltte; CPalette * pPalette;

HRGN hRgn; CRgn * pRgn;

HMENU hMenu; CMenu * pMenu;

HWND hCtl; CState * pState;

HWND hCtl; CButton * pButton;

HWND hCtl; CEdit * pEdit;

HWND hCtl; CListBox * pListBox;

HWND hCtl; CComboBox * pComboBox;

HWND hCtl; CScrollBar * pScrollBar;

HSZ hszStr; CString pStr;

POINT pt; CPoint pt;

SIZE size; CSize size;

RECT rect; CRect rect;

General prefix naming convention:

Prefix & type & instance

C class or struct CDocument,

Hungarian nomenclature is a naming convention when programming. The naming convention is the most important and controversial place in the procedure writing convention. What is the naming convention? Four words: justified. With the dichotomy, the naming conventions are divided into good naming conventions and bad naming conventions, that is to say, well-named and bad-named ones. Good dance shoes are dance shoes that make the dancer not feel their existence, and bad dance shoes are that they dance with shackles. A bad naming convention is much more destructive than a good naming convention.

Some people think that Hungarian nomenclature is a bad naming convention. for example. Taking static strongly typed programming language as an example, the analysis templates are C language and C ++ language. The Hungarian law in the following is the abbreviation of Hungarian nomenclature.

Hungarian nomenclature costs

The expression of Hungarian law is to add a type name prefix to the variable name, for example: nFoo, szFoo, pFoo, cpFoo respectively represent integer variables, string variables, pointer variables and constant pointer variables. It can be seen that the Hungarian law copied the variable type information from a single place (where the variable was declared) to multiple places (where the variable is used), which is a redundant method. One of the costs of the redundant method is to maintain the consistency of the replica. This cost comes when you need to change the type of a variable while writing and maintaining code. The second cost of the redundant method is that it takes up extra space. A good writer will consciously follow a rule: the length of the minimum organizational unit of the code should be less than 30 natural lines, and if it is more than 50 lines, it should be reorganized. The writing space of a variable adds unnecessary difficulty to this rule.

Hungarian nomenclature benefits

The benefits of Hungarian nomenclature are vague and unpredictable.

Template 1: strcpy (pstrFoo, pcstrFoo2) Vs strcpy (foo, foo2)

No programmer will admit that he doesn't know the parameter type of the strcpy function, so the return is zero.

Template 2: unknown_function (nFoo) Vs unknown_function (foo)

The benefits are still not there. For a function that does not know the type, the programmer should check the function's documentation, which is a cost. The only benefit of using the Hungarian method is that people who look at the code know that this function requires an integer parameter, which is of no use. A function is an interface, and the types of parameters are only a small part of the interface. Important information such as the function of the function, exit information, thread safety, exception safety, parameter legitimacy, etc. must still be consulted in the documentation.

Template 3: nFoo = nBar Vs foo = bar

The only advantage of using the Hungarian method is that people who look at the code know that a copy of an integer variable has occurred here. It sounds OK, so you can rest assured. If he sees nFoo = szBar, there is no way to relax. But this is not the case. The first problem should be the compiler. On the other hand, nFoo = nBar is just syntactically legal. People who care about code really care about the legality of semantics. Hungarian law is not helpful for this. On the other hand, a good writer will consciously follow a rule: one or two temporary variables in the smallest organizational unit of the code are appropriate, and if more than three, they should be reorganized. Combining the first rule above, we can conclude that easy-to-understand code itself should be easy to understand, which is the built-in quality of the code. Good naming conventions are of limited benefit to built-in high quality, while bad naming conventions do more damage to built-in quality than people think.

Hungarian nomenclature implementation

Hungarian nomenclature is difficult to implement in C, and it cannot be implemented in C ++.

The Hungarian law is the redundancy of the type system, so the key to implementing the Hungarian law is whether we can accurately replicate the type system. It depends on the complexity of the type system.

C language:

1. Built-in types: int, char, float, double Copy as n, ch, f, d? Seems no problem. But how should void be expressed? The Hungarian law cannot.

2. Combination type: array, union, enum, struct Copy as a, u, e, s? Not convenient.

The difficulty here is not naming the main type, but naming the subtype. an represents an integer array? sfoo, sbar means structure foo, structure bar? ausfoo represents a joint structure foo array? Very verbose.

3. Special type: pointer. Pointer should be a composite type in theory, but it can be considered a built-in type in C language, because C language does not distinguish between different pointer types very strictly.

C ++ language:

1.class: If struct in C language can also use stru to obstruct the past, do not dream of using cls to obfuscate classes in C ++. Strictly speaking, a class is not a type at all, but a tool for creating types. In C ++, the number of built-in types in a language is completely negligible compared to the number of user-defined types created by a class. stdvectorFoo represents the standard library vector type variable Foo, which is illogical.

2. Namespace: boostfilesystemiteratorFoo, indicating that the filesystem subspace of the boost space traverses the directory type variable Foo, which is still not feasible.

3. Template: What is the exact name of the type std :: map <std :: string, std :: string>, which has exceeded 255 characters.

4. Template parameters: template <class T, class BinaryPredicate> const T & max (const T & a, const T & b, BinaryPredicate comp) This one is named with Hungarian nomenclature, which is extremely difficult.

5. Type modification: static, extern, mutable, register, volatile, const, short, long, unsigned plus type modification, it is more difficult.

Hungarian nomenclature has its advantages but also its shortcomings. This requires the use of strengths and avoiding weaknesses in its use, and its reasonable application.