Hungarian notation 匈牙利命名

转载 2013年12月03日 12:01:48
From Wikipedia, the free encyclopedia

Hungarian notation is an identifier naming convention in computer programming, in which the name of a variable or function indicates its type or intended use. There are two types of Hungarian notation: Systems Hungarian notation and Apps Hungarian notation.

Hungarian notation was designed to be language-independent, and found its first major use with the BCPL programming language. Because BCPL has no data types other than the machine word, nothing in the language itself helps a programmer remember variables' types. Hungarian notation aims to remedy this by providing the programmer with explicit knowledge of each variable's data type.

In Hungarian notation, a variable name starts with a group of lower-case letters which are mnemonics for the type or purpose of that variable, followed by whatever name the programmer has chosen; this last part is sometimes distinguished as the given name. The first character of the given name can be capitalized to separate it from the type indicators (see also CamelCase). Otherwise the case of this character denotes scope.

History[edit]

The original Hungarian notation, which would now be called Apps Hungarian, was invented by Charles Simonyi, a programmer who worked at Xerox PARC circa 1972–1981, and who later became Chief Architect at Microsoft. It may have been derived from the earlier principle of using the first letter of a variable name to set its type — for example, variables whose names started with letters I through N in FORTRAN are integers by default.

The notation is a reference to Simonyi's nation of origin; Hungarian people's names are "reversed" compared to most other European names; the family name precedes the given name. For example, the anglicized name "Charles Simonyi" in Hungarian was originally "Simonyi Charles" (Simonyi Károly in Hungarian). In the same way the type name precedes the "given name" in Hungarian notation rather than the more natural, to most Europeans, Smalltalk "type last" naming style e.g. aPoint and lastPoint. This latter naming style was most common at Xerox PARC during Simonyi's tenure there.

The name Apps Hungarian was coined since the convention was used in the applications division of Microsoft. Systems Hungarian developed later in the Microsoft Windows development team. Simonyi's paper referred to prefixes used to indicate the "type" of information being stored. His proposal was largely concerned with decorating identifier names based upon the semantic information of what they store (in other words, the variable's purpose), consistent with Apps Hungarian. However, his suggestions were not entirely distinct from what became known as Systems Hungarian, as some of his suggested prefixes contain little or no semantic information (see below for examples).

The term Hungarian notation is memorable for many people because the strings of unpronounceable consonants vaguely resemble the consonant-rich orthography of some Eastern European languages despite the fact that Hungarian is a Uralic language, and unlike Slavic languages is rather rich in vowels. For example the zero-terminated string prefix "sz" is also a letter in the Hungarian alphabet.

Systems vs. Apps Hungarian[edit]

Where Systems notation and Apps notation differ is in the purpose of the prefixes.

In Systems Hungarian notation, the prefix encodes the actual data type of the variable. For example:

  • lAccountNum : variable is a long integer ("l");
  • arru8NumberList : variable is an array of unsigned 8-bit integers ("arru8");
  • szName : variable is a zero-terminated string ("sz"); this was one of Simonyi's original suggested prefixes.
  • bReadLine(bPort,&arru8NumberList) : function with a byte-value return code.

Apps Hungarian notation strives to encode the logical data type rather than the physical data type; in this way, it gives a hint as to what the variable's purpose is, or what it represents.

  • rwPosition : variable represents a row ("rw");
  • usName : variable represents an unsafe string ("us"), which needs to be "sanitized" before it is used (e.g. see code injection and cross-site scripting for examples of attacks that can be caused by using raw user input)
  • strName : Variable represents a string ("str") containing the name, but does not specify how that string is implemented.

Most, but not all, of the prefixes Simonyi suggested are semantic in nature. The following are examples from the original paper: [1]

  • pX is a pointer to another type X; this contains very little semantic information.
  • d is a prefix meaning difference between two values; for instance, dY might represent a distance along the Y-axis of a graph, while a variable just called y might be an absolute position. This is entirely semantic in nature.
  • sz is a null- or zero-terminated string. In C, this contains some semantic information because it is not clear whether a variable of type char* is a pointer to a single character, an array of characters or a zero-terminated string.
  • w marks a variable that is a word. This contains essentially no semantic information at all, and would probably be considered Systems Hungarian.
  • b marks a byte, which in contrast to w might have semantic information, because in C the only byte-sized data type is the char, so these are sometimes used to hold numeric values. This prefix might clear ambiguity between whether the variable is holding a value that should be treated as a character or a number.

While the notation always uses initial lower-case letters as mnemonics, it does not prescribe the mnemonics themselves. There are several widely used conventions (see examples below), but any set of letters can be used, as long as they are consistent within a given body of code.

It is possible for code using Apps Hungarian notation to sometimes contain Systems Hungarian when describing variables that are defined solely in terms of their type.

Relation to sigils[edit]

In some programming languages, a similar notation now called sigils is built into the language and enforced by the compiler. For example, in some forms of BASIC,name$ names a string and count% names an integer. The major difference between Hungarian notation and sigils is that sigils declare the type of the variable to the compiler, while Hungarian notation is purely a naming scheme.

Examples[edit]

  • bBusy : boolean
  • chInitial : char
  • cApples : count of items
  • dwLightYears : double word (Systems)
  • fBusy : boolean (flag)
  • nSize : integer (Systems) or count (Apps)
  • iSize : integer (Systems) or index (Apps)
  • fpPricefloating-point
  • dbPi : double (Systems)
  • pFoo : pointer
  • rgStudents : array, or range
  • szLastName : zero-terminated string
  • u32Identifier : unsigned 32-bit integer (Systems)
  • stTime : clock time structure
  • fnFunction : function name

The mnemonics for pointers and arrays, which are not actual data types, are usually followed by the type of the data element itself:

  • pszOwner : pointer to zero-terminated string
  • rgfpBalances : array of floating-point values
  • aulColors : array of unsigned long (Systems)

While Hungarian notation can be applied to any programming language and environment, it was widely adopted by Microsoft for use with the C language, in particular for Microsoft Windows, and its use remains largely confined to that area. In particular, use of Hungarian notation was widely evangelized by Charles Petzold's "Programming Windows", the original (and for many readers, the definitive) book on Windows API programming. Thus, many commonly seen constructs of Hungarian notation are specific to Windows:

  • For programmers who learned Windows programming in C, probably the most memorable examples are the wParam (word-size parameter) and lParam (long-integer parameter) for the WindowProc() function.
  • hwndFoo : handle to a window
  • lpszBar : long pointer to a zero-terminated string

The notation is sometimes extended in C++ to include the scope of a variable, separated by an underscore[citation needed]. This extension is often also used without the Hungarian type-specification:

  • g_nWheels : member of a global namespace, integer
  • m_nWheels : member of a structure/class, integer
  • m_wheels_wheels : member of a structure/class
  • s_wheels : static member of a class
  • c_wheels : static member of a function

Advantages[edit]

(Some of these apply to Systems Hungarian only.)

Supporters argue that the benefits of Hungarian Notation include:[1]

  • The variable type can be seen from its name. (This is particularly useful when looking at the code outside an integrated development environment - like on a printout).
  • In a language that uses dynamic typing or that is completely untyped, the decorations that refer to types cease to be redundant. In such languages variables are typically not declared as holding a particular type of data, so the only clue as to what operations can be done on it are hints given by the programmer, such as a variable naming scheme, documentation and comments. As mentioned above, Hungarian Notation expanded in such a language (BCPL).
  • The type of value returned by a function is determined without lookup (i.e. searching for function definitions in other files, e.g. ".h" header files, etc.)
  • The formatting of variable names may simplify some aspects of code refactoring (while making some aspects more error-prone).
  • Multiple variables with similar semantics can be used in a block of code: dwWidth, iWidth, fWidth, dWidth
  • Variable names can be easy to remember from knowing just their types.
  • It leads to more consistent variable names
  • Inappropriate type casting and operations using incompatible types can be detected easily while reading code
  • In Apps Hungarian, the variable name guards against using it in an improper operation with the same data type by making the error obvious as in:
heightWindow = window.getWidth()
  • In complex programs with lots of global objects (VB/Delphi Forms), having a basic prefix notation can ease the work of finding the component inside of the editor. Typing btn and pressing <Ctrl-Space> causes the editor to pop up a list of Button objects.
  • Applying Hungarian notation in a narrower way, such as applying only for member variables helps avoiding naming collision.

Disadvantages[edit]

Most arguments against Hungarian notation are against Systems Hungarian notation, not Apps Hungarian notation. Some potential issues are:

  • The Hungarian notation is redundant when type-checking is done by the compiler. Compilers for languages providing type-checking ensure the usage of a variable is consistent with its type automatically; checks by eye are redundant and subject to human error.
  • All modern integrated development environments display variable types on demand, and automatically flag operations which use incompatible types, 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 or ported. 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. A particularly well known example is the standard WPARAM type, and the accompanying wParamformal parameter in many Windows system function declarations. The 'w' stands for 'word', where 'word' is the native word size of the platform's hardware architecture. It was originally a 16 bit type on 16-bit word architectures, but was changed to a 32-bit on 32-bit word architectures, or 64-bit type on 64-bit word architectures 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). The semantic impedance, and hence programmer confusion and inconsistency from platform-to-platform, is on the assumption that 'w' stands for 16-bit in those different environments.
  • Most of the time, knowing the use of a variable implies knowing its type. Furthermore, if the usage of a variable is not known, it cannot be deduced from its type.
  • Hungarian notation reduces the benefits of using code editors that support completion on variable names, for the programmer has to input the type specifier first, which is more likely to collide with other variables than when using other naming schemes.
  • It makes code less readable, by obfuscating the purpose of the variable with needless type and scoping prefixes.[2]
  • The additional type information can insufficiently replace more descriptive names. E.g. sDatabase does not tell the reader what it is. databaseName might be a more descriptive name.
  • When names are sufficiently descriptive, the additional type information can be redundant. E.g. firstName is most likely a string. So naming it sFirstName only adds clutter to the code.
  • It's harder to remember the names.
  • Multiple variables with different semantics can be used in a block of code with similar names: dwTmp, iTmp, fTmp, dTmp.

Notable opinions[edit]

  • Robert C. Martin (against Hungarian notation and all other forms of encoding):

    ".. nowadays HN and other forms of type encoding are simply impediments. They make it harder to change the name or type of a variable, function, member or class. They make it harder to read the code. And they create the possibility that the encoding system will mislead the reader."[3]

  • Linus Torvalds (against Systems Hungarian):

    "Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged—the compiler knows the types anyway and can check those, and it only confuses the programmer."[4]

  • Steve McConnell (for Hungarian):

    "Although the Hungarian naming convention is no longer in widespread use, the basic idea of standardizing on terse, precise abbreviations continues to have value. Standardized prefixes allow you to check types accurately when you're using abstract data types that your compiler can't necessarily check."[5]

  • Bjarne Stroustrup (against Systems Hungarian for C++):

    "No I don't recommend 'Hungarian'. I regard 'Hungarian' (embedding an abbreviated version of a type in a variable name) a technique that can be useful in untyped languages, but is completely unsuitable for a language that supports generic programming and object-oriented programming—both of which emphasize selection of operations based on the type an arguments (known to the language or to the run-time support). In this case, 'building the type of an object into names' simply complicates and minimizes abstraction."[6]

  • Joel Spolsky (for Apps Hungarian):

    "If you read Simonyi's paper closely, what he was getting at was the same kind of naming convention as I used in my example above where we decided that us meant "unsafe string" and s meant "safe string." They're both of type string. The compiler won't help you if you assign one to the other and Intellisense won't tell you bupkis. But they are semantically different. They need to be interpreted differently and treated differently and some kind of conversion function will need to be called if you assign one to the other or you will have a runtime bug. If you're lucky. There's still a tremendous amount of value to Apps Hungarian, in that it increases collocation in code, which makes the code easier to read, write, debug, and maintain, and, most importantly, it makes wrong code look wrong."[7]

  • Microsoft's Design Guidelines[8] discourage developers from using Hungarian notation when they choose names for the elements in .NET Class Libraries, although it was common on prior Microsoft development platforms like Visual Basic 6 and earlier. These Design Guidelines are silent on the naming conventions for local variables inside functions.

See also[edit]

References[edit]

  1. Jump up to:a b Charles Simonyi (November 1999). "Hungarian Notation"MSDN LibraryMicrosoft Corp.
  2. Jump up^ Jones, Derek M. (2009). The New C Standard: A Cultural and Economic Commentary. Addison-Wesley. p. 727. ISBN 0-201-70917-1.
  3. Jump up^ Robert C. Martin (2008). "Clean Code: A Handbook of Agile Software Craftsmanship". Redmond, WA: Prentice Hall PTR. ISBN ISBN 0-13-235088-2.
  4. Jump up^ "Linux kernel coding style"Linux kernel documentation.
  5. Jump up^ Steve McConnell (2004). Code Complete (2nd ed.). Redmond, WA: Microsoft PressISBN 0-7356-1967-0.
  6. Jump up^ Bjarne Stroustrup (2007). "Bjarne Stroustrup's C++ Style and Technique FAQ".
  7. Jump up^ Joel Spolsky (2005-05-11). "Making Wrong Code Look Wrong"Joel on Software. Retrieved 2005-12-13.
  8. Jump up^ "Design Guidelines for Developing Class Libraries: General Naming Conventions". Retrieved 2008-01-03.

External links[edit]

匈牙利命名法的衰落和建议

首先要说明的是,此文只是一篇关于个人看法的随笔,不是paper。我也无意再次挑起这场旷日持久却已结束的争论。 1.不太久远的历史 匈牙利命名法(Hungarian Nota...
  • yangluoning
  • yangluoning
  • 2013年09月13日 09:28
  • 3128

匈牙利表示法(Hungarian Notation)

Win32asm源程序风格采用匈牙利表示法,是由Microsoft公司的程序设计人员Charles Simonyi首创的。在匈牙利表示法中,变量名以一个或多个小写字母开始,代表变量的类型。后面附以变量...
  • hustspy1990
  • hustspy1990
  • 2009年10月23日 07:43
  • 2731

Hungarian Algorithm(匈牙利算法)

本文简单介绍 Hungarian Algorithm(匈牙利算法) 及其矩阵表示下的操作流程。翻译自维基百科。...
  • u011837761
  • u011837761
  • 2016年07月28日 20:24
  • 5590

Hungarian Notation

Hungarian Notation is a naming convention in which the type and/or scope of a variable is used as a ...
  • wetgsg
  • wetgsg
  • 2014年07月24日 16:32
  • 376

我眼中的匈牙利命名法

上个月Linus通过Linux内核邮件列表一怒为注释,要求内核开发者“get rid of thebrain-damaged stupid networking comment syntax st...
  • tintinr
  • tintinr
  • 2016年09月04日 23:25
  • 1895

两种编程命名规则(匈牙利法、大小驼峰法)

1. 匈牙利命名法      开头字母用变量类型的缩写,其余部分用变量的英文或英文的缩写,要求单词第一个字母大写。      比如:   long lSum = 0;       //"l"是类型...
  • u010820135
  • u010820135
  • 2016年07月03日 21:43
  • 3172

匈牙利算法的C++实现(基于OpenCV)

Hungarian Algorithm
  • j56754gefge
  • j56754gefge
  • 2014年11月04日 21:24
  • 1600

Hungarian notation for ActionScript 匈牙利前缀AS版

应该养成的习惯,恩 a           Arraybmp       BitmapDatab           Booleanbt          Buttonc           Colo...
  • linus1115
  • linus1115
  • 2007年09月13日 01:21
  • 400

匈牙利命名法规范

匈牙利命名法是电脑程序设计中的一种变量命名规则,此命名法又可细分为:系统匈牙利命名法和匈牙利应用命名法。 系统命名法与应用命名法的区别在于前缀的目的。 在系统匈牙利命名法中,前缀代表了变量的实际数...
  • zhiweiarm
  • zhiweiarm
  • 2013年05月24日 10:25
  • 1321

变量的命名方法【Hungarian】【camelCase】【PascalCase】

变量的命名方法【Hungarian】【camelCase】【PascalCase】 一、匈牙利命名法【Hungarian】:       广泛应用于象Microsoft Windows...
  • tangxinzitxz
  • tangxinzitxz
  • 2011年09月23日 00:06
  • 730
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:Hungarian notation 匈牙利命名
举报原因:
原因补充:

(最多只允许输入30个字)