I don't use a very strict sense of hungarian notation, but I do find myself using it sparing for some common custom objects to help identify them, and also I tend to prefix gui control objects with the type of control that they are. For example, labelFirstName, textFirstName, and buttonSubmit.
Isn't scope more important than type these days, e.g.
l for local
a for argument
m for member
g for global
etc
With modern techniques of refactoring old code, search and replace of a symbol because you changed its type is tedious, the compiler will catch type changes, but often will not catch incorrect use of scope, sensible naming conventions help here.
I still use Hungarian Notation when it comes to UI elements, where several UI elements are related to a particular object/value, e.g.,
lblFirstName for the label object, txtFirstName for the text box. I definitely can't name them both "FirstName" even if that is the concern/responsibility of both objects.
Being a PHP programmer where it's very loosely typed, I don't make a point to use it. However I will occasionally identify something as an array or as an object depending on the size of the system and the scope of the variable.
I use type based (Systems HN) for components (eg editFirstName, lblStatus etc) as it makes autocomplete work better.
I sometimes use App HN for variables where the type infomation is isufficient. Ie fpX indicates a fixed pointed variable (int type, but can't be mixed and matched with an int), rawInput for user strings that haven't been validated etc
Original form (The Right Hungarian Notation :) ) where prefix means type (i.e. length, quantity) of value stored by variable is OK, but not necessary in all type of applications.
The popular form (The Wrong Hungarian Notation) where prefix means type (String, int) is useless in most of modern programming languages.
Especially with meaningless names like strA. I can't understand we people use meaningless names with long prefixes which gives nothing.
It depends on your language and environment. As a rule I wouldn't use it, unless the development environment you're in makes it hard to find the type of the variable.
There's also two different types of Hungarian notation. See Joel's article. I can't find it (his names don't exactly make them easy to find), anyone have a link to the one I mean?
Essentially, type based Hungarian notation, where variables are prefixed with information about their type (e.g. whether an object is a string, a handle, an int, etc.) is mostly useless and generally just adds overhead with very little benefit. This, sadly, is the Hungarian notation most people are familiar with. However, the intent of Hungarian notation as envisioned is to add information on the "kind" of data the variable contains. This allows you to partition kinds of data from other kinds of data which shouldn't be allowed to be mixed together except, possibly, through some conversion process. For example, pixel based coordinates vs. coordinates in other units, or unsafe user input versus data from safe sources, etc.
Look at it this way, if you find yourself spelunking through code to find out information on a variable then you probably need to adjust your naming scheme to contain that information, this is the essence of the Hungarian convention.
Note that an alternative to Hungarian notation is to use more classes to show the intent of variable usage rather than relying on primitive types everywhere. For example, instead of having variable prefixes for unsafe user input, you can have simple string wrapper class for unsafe user input, and a separate wrapper class for safe data. This has the advantage, in strongly typed languages, of having partitioning enforced by the compiler (even in less strongly typed languages you can usually add your own tripwire code) but adds a not insignificant amount of overhead.
When I see Hungarian discussion, I'm glad to see people thinking hard about how to make their code clearer, and how to mistakes more visible. That's exactly what we should all be doing!
But don't forget that you have some powerful tools at your disposal besides naming.
Extract Method If your methods are getting so long that your variable declarations have scrolled off the top of the screen, consider making your methods smaller. (If you have too many methods, consider a new class.)
Strong typing If you find that you are taking zip codes stored in an integer variable and assigning them to a shoe size integer variable, consider making a class for zip codes and a class for shoe size. Then your bug will be caught at compile time, instead of requiring careful inspection by a human. When I do this, I usually find a bunch of zip code- and shoe size-specific logic that I've peppered around my code, which I can then move in to my new classes. Suddenly all my code gets clearer, simpler, and protected from certain classes of bugs. Wow.
To sum up: yes, think hard about how you use names in code to express your ideas clearly, but also look to the other powerful OO tools you can call on.
Sorry to follow up with a question, but does prefixing interfaces with "I" qualify as hungarian notation? If that is the case, then yes, a lot of people are using it in the real world. If not, ignore this.
I use Hungarian Naming for UI elements like buttons, textboxes and lables. The main benefit is grouping in the Visual Studio Intellisense Popup. If I want to access my lables, I simply start typing lbl.... and Visual Studio will suggest all my lables, nicley grouped together.
However, after doing more and more Silverlight and WPF stuff, leveraging data binding, I don't even name all my controls anymore, since I don't have to reference them from code-behind (since there really isn't any codebehind anymore ;)
Considering that most people that use Hungarian Notation is following the misunderstood version of it, I'd say it's pretty pointless.
If you want to use the original definition of it, it might make more sense, but other than that it is mostly syntactic sugar.
If you read the Wikipedia article on the subject, you'll find two conflicting notations, Systems Hungarian Notation and Apps Hungarian Notation.
The original, good, definition is the Apps Hungarian Notation, but most people use the Systems Hungarian Notation.
As an example of the two, consider prefixing variables with l for length, a for area and v for volume.
With such notation, the following expression makes sense:
int vBox = aBottom * lVerticalSide;
but this doesn't:
int aBottom = lSide1;
If you're mixing the prefixes, they're to be considered part of the equation, and volume = area * length is fine for a box, but copying a length value into an area variable should raise some red flags.
Unfortunately, the other notation is less useful, where people prefix the variable names with the type of the value, like this:
int iLength;
int iVolume;
int iArea;
some people use n for number, or i for integer, f for float, s for string etc.
The original prefix was meant to be used to spot problems in equations, but has somehow devolved into making the code slightly easier to read since you don't have to go look for the variable declaration. With todays smart editors where you can simply hover over any variable to find the full type, and not just an abbreviation for it, this type of hungarian notation has lost a lot of its meaning.
But, you should make up your own mind. All I can say is that I don't use either.
Edit Just to add a short notice, while I don't use Hungarian Notation, I do use a prefix, and it's the underscore. I prefix all private fields of classes with a _ and otherwise spell their names as I would a property, titlecase with the first letter uppercase.
I see Hungarian Notation as a way to circumvent the capacity of our short term memories. According to psychologists, we can store approximately 7 plus-or-minus 2 chunks of information. The extra information added by including a prefix helps us by providing more details about the meaning of an identifier even with no other context. In other words, we can guess what a variable is for without seeing how it is used or declared. This can be avoided by applying oo techniques such as encapsulation and the single responsibility principle.
I'm unaware of whether or not this has been studied empirically. I would hypothesize that the amount of effort increases dramatically when we try to understand classes with more than nine instance variables or methods with more than 9 local variables.
The original prefix was meant to be used to spot problems in equations, but has somehow devolved into making the code slightly easier to read since you don't have to go look for the variable declaration. With todays smart editors where you can simply hover over any variable to find the full type, and not just an abbreviation for it, this type of hungarian notation has lost a lot of its meaning.
I'm breaking the habit a little bit but prefixing with the type can be useful in JavaScript that doesn't have strong variable typing.
When using a dynamically typed language, I occasionally use Apps Hungarian. For statically typed languages I don't. See my explanation in the other thread.
Hungarian notation is pointless in type-safe languages. e.g. A common prefix you will see in old Microsoft code is "lpsz" which means "long pointer to a zero-terminated string". Since the early 1700's we haven't used segmented architectures where short and long pointers exist, the normal string representation in C++ is always zero-terminated, and the compiler is type-safe so won't let us apply non-string operations to the string. Therefore none of this information is of any real use to a programmer - it's just more typing.
However, I use a similar idea: prefixes that clarify the usage of a variable. The main ones are:
m = member
c = const
s = static
v = volatile
p = pointer (and pp=pointer to pointer, etc)
i = index or iterator
These can be combined, so a static member variable which is a pointer would be "mspName".
Where are these useful?
Where the usage is important, it is a good idea to constantly remind the programmer that a variable is (e.g.) a volatile or a pointer
Pointer dereferencing used to do my head in until I used the p prefix. Now it's really easy to know when you have an object (Orange) a pointer to an object (pOrange) or a pointer to a pointer to an object (ppOrange). To dereference an object, just put an asterisk in front of it for each p in its name. Case solved, no more deref bugs!
In constructors I usually find that a parameter name is identical to a member variable's name (e.g. size). I prefer to use "mSize = size;" than "size = theSize" or "this.size = size". It is also much safer: I don't accidentally use "size = 1" (setting the parameter) when I meant to say "mSize = 1" (setting the member)
In loops, my iterator variables are all meaningful names. Most programmers use "i" or "index" and then have to make up new meaningless names ("j", "index2") when they want an inner loop. I use a meaningful name with an i prefix (iHospital, iWard, iPatient) so I always know what an iterator is iterating.
In loops, you can mix several related variables by using the same base name with different prefixes: Orange orange = pOrange[iOrange]; This also means you don't make array indexing errors (pApple[i] looks ok, but write it as pApple[iOrange] and the error is immediately obvious).
Many programmers will use my system without knowing it: by add a lengthy suffix like "Index" or "Ptr" - there isn't any good reason to use a longer form than a single character IMHO, so I use "i" and "p". Less typing, more consistent, easier to read.
This is a simple system which adds meaningful and useful information to code, and eliminates the possibility of many simple but common programming mistakes.
发布评论
评论（20）
我没有使用非常严格意义上的匈牙利表示法，但我确实发现自己在一些常见的自定义对象上使用它来帮助识别它们，而且我倾向于在 gui 控件对象前面加上它们的控件类型。 例如，labelFirstName、textFirstName 和 buttonSubmit。
I don't use a very strict sense of hungarian notation, but I do find myself using it sparing for some common custom objects to help identify them, and also I tend to prefix gui control objects with the type of control that they are. For example, labelFirstName, textFirstName, and buttonSubmit.
如今，范围不是比类型更重要吗，例如
使用重构旧代码的现代技术，搜索和替换符号（因为您更改了其类型）是乏味的，编译器将捕获类型更改，但通常不会捕获范围的错误使用，明智的命名约定在这里有所帮助。
Isn't scope more important than type these days, e.g.
With modern techniques of refactoring old code, search and replace of a symbol because you changed its type is tedious, the compiler will catch type changes, but often will not catch incorrect use of scope, sensible naming conventions help here.
当涉及到 UI 元素时，我仍然使用匈牙利表示法，其中多个 UI 元素与特定对象/值相关，例如，
lblFirstName 表示标签对象，txtFirstName 表示文本框。 我绝对不能将它们命名为“FirstName”，即使这是两个对象的关注点/责任。
其他人如何命名 UI 元素？
I still use Hungarian Notation when it comes to UI elements, where several UI elements are related to a particular object/value, e.g.,
lblFirstName for the label object, txtFirstName for the text box. I definitely can't name them both "FirstName" even if that is the concern/responsibility of both objects.
How do others approach naming UI elements?
作为一名 PHP 程序员，它的类型非常松散，我不打算使用它。 然而，我偶尔会根据系统的大小和变量的范围将某些东西识别为数组或对象。
Being a PHP programmer where it's very loosely typed, I don't make a point to use it. However I will occasionally identify something as an array or as an object depending on the size of the system and the scope of the variable.
我对组件（例如 editFirstName、lblStatus 等）使用基于类型（Systems HN），因为它使自动完成工作更好。
我有时将 App HN 用于类型信息充足的变量。 即fpX表示固定指向变量（int类型，但不能与int混合匹配），rawInput表示尚未验证的用户字符串等
I use type based (Systems HN) for components (eg editFirstName, lblStatus etc) as it makes autocomplete work better.
I sometimes use App HN for variables where the type infomation is isufficient. Ie fpX indicates a fixed pointed variable (int type, but can't be mixed and matched with an int), rawInput for user strings that haven't been validated etc
原始形式（正确的匈牙利表示法:)）其中前缀表示变量存储的值的类型（即长度、数量）是可以的，但并非在所有类型的应用程序中都是必需的。
前缀表示类型（String、int）的流行形式（错误的匈牙利表示法）在大多数现代编程语言中都是无用的。
尤其是像 strA 这样毫无意义的名字。 我无法理解我们人们使用带有长前缀的无意义名称，这没有给出任何信息。
Original form (The Right Hungarian Notation :) ) where prefix means type (i.e. length, quantity) of value stored by variable is OK, but not necessary in all type of applications.
The popular form (The Wrong Hungarian Notation) where prefix means type (String, int) is useless in most of modern programming languages.
Especially with meaningless names like strA. I can't understand we people use meaningless names with long prefixes which gives nothing.
这取决于您的语言和环境。 通常我不会使用它，除非您所处的开发环境使得很难找到变量的类型。
还有两种不同类型的匈牙利表示法。 参见乔尔的文章。 我找不到它（他的名字并不容易找到），有人有我所说的链接吗？
编辑：Wedge 在他的帖子中有我所说的文章。
It depends on your language and environment. As a rule I wouldn't use it, unless the development environment you're in makes it hard to find the type of the variable.
There's also two different types of Hungarian notation. See Joel's article. I can't find it (his names don't exactly make them easy to find), anyone have a link to the one I mean?
Edit: Wedge has the article I mean in his post.
我认为匈牙利表示法是通向更具可读性的代码的“路径”上的一个有趣的脚注，如果做得正确，比不做更好。
尽管如此，我还是宁愿放弃它，而不是这样
写：
现在是 2008 年。我们不再有 80 个字符的固定宽度屏幕了！
另外，如果您编写的变量名称比您应该考虑的要长得多的变量名称重构为对象或函数。
I think hungarian notation is an interesting footnote along the 'path' to more readable code, and if done properly, is preferable to not-doing it.
In saying that though, I'd rather do away with it, and instead of this:
write this:
It's 2008. We don't have 80 character fixed width screens anymore!
Also, if you're writing variable names which are much longer than that you should be looking at refactoring into objects or functions anyway.
它毫无意义（而且令人分心），但在我的公司中使用相对较多，至少对于整数、字符串、布尔值和双精度类型而言。
诸如
sValue、iCount、dAmount或fAmount以及bFlag之类的东西无处不在。曾几何时，召开这个会议是有充分理由的。 现在，它是一种癌症。
It is pointless (and distracting) but is in relatively heavy use at my company, at least for types like ints, strings, booleans, and doubles.
Things like
sValue,iCount,dAmountorfAmount, andbFlagare everywhere.Once upon a time there was a good reason for this convention. Now, it is a cancer.
如果正确使用，匈牙利命名惯例会很有用，但不幸的是，它往往被误用。
请阅读 Joel Spolsky 的文章让错误的代码看起来错误以获得适当的观点和理由。
本质上，基于类型的匈牙利表示法，其中变量以有关其类型的信息为前缀（例如，对象是否是字符串、句柄、整数等），几乎没有用处，并且通常只会增加开销，但好处很少。 遗憾的是，这是大多数人都熟悉的匈牙利表示法。 然而，匈牙利表示法的目的是添加有关变量包含的数据“种类”的信息。 这允许您将不同类型的数据与其他类型的数据分开，这些数据不允许混合在一起，除非可能通过某些转换过程。 例如，基于像素的坐标与其他单位的坐标，或者不安全的用户输入与来自安全来源的数据等。
这样看，如果您发现自己正在通过代码来查找有关变量的信息，那么您可能需要调整您的命名方案以包含该信息，这是匈牙利惯例的精髓。
请注意，匈牙利表示法的替代方法是使用更多的类来显示变量使用的意图，而不是到处依赖原始类型。 例如，您可以为不安全的用户输入使用简单的字符串包装类，并为安全数据使用单独的包装类，而不是为不安全的用户输入使用变量前缀。 在强类型语言中，这样做的优点是由编译器强制执行分区（即使在不太强类型的语言中，您通常也可以添加自己的 tripwire 代码），但会增加不小的开销。
The Hungarian Naming Convention can be useful when used correctly, unfortunately it tends to be misused more often than not.
Read Joel Spolsky's article Making Wrong Code Look Wrong for appropriate perspective and justification.
Essentially, type based Hungarian notation, where variables are prefixed with information about their type (e.g. whether an object is a string, a handle, an int, etc.) is mostly useless and generally just adds overhead with very little benefit. This, sadly, is the Hungarian notation most people are familiar with. However, the intent of Hungarian notation as envisioned is to add information on the "kind" of data the variable contains. This allows you to partition kinds of data from other kinds of data which shouldn't be allowed to be mixed together except, possibly, through some conversion process. For example, pixel based coordinates vs. coordinates in other units, or unsafe user input versus data from safe sources, etc.
Look at it this way, if you find yourself spelunking through code to find out information on a variable then you probably need to adjust your naming scheme to contain that information, this is the essence of the Hungarian convention.
Note that an alternative to Hungarian notation is to use more classes to show the intent of variable usage rather than relying on primitive types everywhere. For example, instead of having variable prefixes for unsafe user input, you can have simple string wrapper class for unsafe user input, and a separate wrapper class for safe data. This has the advantage, in strongly typed languages, of having partitioning enforced by the compiler (even in less strongly typed languages you can usually add your own tripwire code) but adds a not insignificant amount of overhead.
当我看到匈牙利的讨论时，我很高兴看到人们认真思考如何使他们的代码更清晰，以及如何使错误更加明显。 这正是我们都应该做的！
但不要忘记，除了命名之外，您还可以使用一些强大的工具。
提取方法 如果您的方法变得太长，以至于您的变量声明已经滚动到屏幕顶部之外，请考虑缩小您的方法。 （如果您有太多方法，请考虑一个新类。）
强类型如果您发现您正在获取存储在整数变量中的邮政编码并将它们分配给鞋码整数变量，考虑为邮政编码创建一个类，并为鞋码创建一个类。 然后你的错误将在编译时被捕获，而不需要人工仔细检查。 当我这样做时，我通常会发现一堆邮政编码和鞋号特定的逻辑，我将它们散布在我的代码中，然后我可以将其移至我的新类中。 突然间，我的所有代码都变得更加清晰、简单，并且免受某些类别的错误的影响。 哇。
总结一下：是的，请认真思考如何在代码中使用名称来清楚地表达您的想法，但也要考虑您可以调用的其他强大的 OO 工具。
When I see Hungarian discussion, I'm glad to see people thinking hard about how to make their code clearer, and how to mistakes more visible. That's exactly what we should all be doing!
But don't forget that you have some powerful tools at your disposal besides naming.
Extract Method If your methods are getting so long that your variable declarations have scrolled off the top of the screen, consider making your methods smaller. (If you have too many methods, consider a new class.)
Strong typing If you find that you are taking zip codes stored in an integer variable and assigning them to a shoe size integer variable, consider making a class for zip codes and a class for shoe size. Then your bug will be caught at compile time, instead of requiring careful inspection by a human. When I do this, I usually find a bunch of zip code- and shoe size-specific logic that I've peppered around my code, which I can then move in to my new classes. Suddenly all my code gets clearer, simpler, and protected from certain classes of bugs. Wow.
To sum up: yes, think hard about how you use names in code to express your ideas clearly, but also look to the other powerful OO tools you can call on.
很抱歉提出一个问题，但是在接口上添加“I”前缀是否符合匈牙利表示法？ 如果是这样的话，那么是的，很多人在现实世界中使用它。 如果没有，请忽略这一点。
Sorry to follow up with a question, but does prefixing interfaces with "I" qualify as hungarian notation? If that is the case, then yes, a lot of people are using it in the real world. If not, ignore this.
我对按钮、文本框和标签等 UI 元素使用匈牙利命名。 主要好处是在 Visual Studio Intellisense 弹出窗口中进行分组。 如果我想访问我的标签，我只需开始输入 lbl...，Visual Studio 就会建议我所有的标签，nicley 分组在一起。
然而，在做了越来越多的 Silverlight 和 WPF 工作并利用数据绑定之后，我什至不再命名所有控件，因为我不必从代码隐藏中引用它们（因为实际上不再有任何代码隐藏了） ;)
I use Hungarian Naming for UI elements like buttons, textboxes and lables. The main benefit is grouping in the Visual Studio Intellisense Popup. If I want to access my lables, I simply start typing lbl.... and Visual Studio will suggest all my lables, nicley grouped together.
However, after doing more and more Silverlight and WPF stuff, leveraging data binding, I don't even name all my controls anymore, since I don't have to reference them from code-behind (since there really isn't any codebehind anymore ;)
考虑到大多数使用匈牙利表示法的人都遵循其被误解的版本，我认为这是毫无意义的。
如果你想使用它的原始定义，它可能更有意义，但除此之外它主要是语法糖。
如果您阅读有关该主题的维基百科文章，您会发现两个相互冲突的符号，系统匈牙利表示法和应用匈牙利表示法。
最初的、好的定义是应用匈牙利表示法，但大多数人使用系统匈牙利表示法。
作为两者的示例，请考虑为变量添加前缀 l（表示长度）、a（表示面积）和 v（表示体积）。
使用这种表示法，以下表达式有意义：
但事实并非如此：
如果您混合前缀，它们将被视为等式的一部分，并且体积 = 面积 * 长度对于盒子来说很好，但是复制将长度值放入区域变量中应该会引发一些危险信号。
不幸的是，另一种表示法不太有用，人们在变量名前加上值的类型前缀，如下所示：
有些人使用 n 表示数字，或 i 表示整数，f 表示浮点数，s 表示字符串等。
原始前缀是本来是用来发现方程中的问题，但不知何故已经转变为使代码更容易阅读，因为您不必去寻找变量声明。 在当今的智能编辑器中，您只需将鼠标悬停在任何变量上即可找到完整类型，而不仅仅是其缩写，这种类型的匈牙利表示法已经失去了很多意义。
但是，你应该自己做出决定。 我只能说我两个都不用。
编辑只是添加一个简短的通知，虽然我不使用匈牙利表示法，但我确实使用了一个前缀，它就是下划线。 我为类的所有私有字段添加前缀 _ ，并以其他方式拼写它们的名称，就像属性一样，标题首字母大写。
Considering that most people that use Hungarian Notation is following the misunderstood version of it, I'd say it's pretty pointless.
If you want to use the original definition of it, it might make more sense, but other than that it is mostly syntactic sugar.
If you read the Wikipedia article on the subject, you'll find two conflicting notations, Systems Hungarian Notation and Apps Hungarian Notation.
The original, good, definition is the Apps Hungarian Notation, but most people use the Systems Hungarian Notation.
As an example of the two, consider prefixing variables with l for length, a for area and v for volume.
With such notation, the following expression makes sense:
but this doesn't:
If you're mixing the prefixes, they're to be considered part of the equation, and volume = area * length is fine for a box, but copying a length value into an area variable should raise some red flags.
Unfortunately, the other notation is less useful, where people prefix the variable names with the type of the value, like this:
some people use n for number, or i for integer, f for float, s for string etc.
The original prefix was meant to be used to spot problems in equations, but has somehow devolved into making the code slightly easier to read since you don't have to go look for the variable declaration. With todays smart editors where you can simply hover over any variable to find the full type, and not just an abbreviation for it, this type of hungarian notation has lost a lot of its meaning.
But, you should make up your own mind. All I can say is that I don't use either.
Edit Just to add a short notice, while I don't use Hungarian Notation, I do use a prefix, and it's the underscore. I prefix all private fields of classes with a _ and otherwise spell their names as I would a property, titlecase with the first letter uppercase.
过去 6 个月我一直在 IBM 工作，但我在任何地方都没有看到它（感谢上帝，因为我讨厌它。）我看到的要么是驼峰命名法，要么是 c_style。
I've been working for IBM for the past 6 months and I haven't seen it anywhere (thank god because I hate it.) I see either camelCase or c_style.
我认为匈牙利表示法是一种规避我们短期记忆能力的方法。 根据心理学家的说法，我们可以存储大约7 加减 2 块 信息。 通过包含前缀添加的额外信息可以帮助我们提供有关标识符含义的更多详细信息，即使没有其他上下文也是如此。 换句话说，我们可以猜测变量的用途，而无需查看它是如何使用或声明的。 这可以通过应用面向对象技术来避免，例如封装和单一责任原则。
我不知道这是否已经过实证研究。 我假设，当我们尝试理解具有超过 9 个实例变量的类或具有超过 9 个局部变量的方法时，工作量会急剧增加。
I see Hungarian Notation as a way to circumvent the capacity of our short term memories. According to psychologists, we can store approximately 7 plus-or-minus 2 chunks of information. The extra information added by including a prefix helps us by providing more details about the meaning of an identifier even with no other context. In other words, we can guess what a variable is for without seeing how it is used or declared. This can be avoided by applying oo techniques such as encapsulation and the single responsibility principle.
I'm unaware of whether or not this has been studied empirically. I would hypothesize that the amount of effort increases dramatically when we try to understand classes with more than nine instance variables or methods with more than 9 local variables.
问题在于混合标准。
正确的做法是确保每个人都做同样的事情。
What's wrong is mixing standards.
What's right is making sure that everyone does the same thing.
我稍微打破了这个习惯，但是在没有强变量类型的 JavaScript 中，使用类型前缀可能很有用。
I'm breaking the habit a little bit but prefixing with the type can be useful in JavaScript that doesn't have strong variable typing.
使用动态类型语言时，我偶尔会使用 Apps Hungarian。 对于静态类型语言，我不这样做。 请参阅我的解释在另一个线程中。
When using a dynamically typed language, I occasionally use Apps Hungarian. For statically typed languages I don't. See my explanation in the other thread.
匈牙利表示法在类型安全语言中毫无意义。 例如，您将在旧的 Microsoft 代码中看到的常见前缀是“lpsz”，这意味着“指向以零结尾的字符串的长指针”。 自 1700 年代初期以来，我们还没有使用存在短指针和长指针的分段体系结构，C++ 中的正常字符串表示形式始终以零终止，并且编译器是类型安全的，因此不允许我们将非字符串操作应用于细绳。 因此，这些信息对程序员来说没有任何实际用处——它只是更多的打字而已。
然而，我使用了类似的想法：澄清变量用法的前缀。
主要是：
这些可以组合，因此作为指针的静态成员变量将是“mspName”。
这些有什么用呢？
这是一个简单的系统，它向代码添加了有意义且有用的信息，并消除了许多简单但常见的编程错误的可能性。
Hungarian notation is pointless in type-safe languages. e.g. A common prefix you will see in old Microsoft code is "lpsz" which means "long pointer to a zero-terminated string". Since the early 1700's we haven't used segmented architectures where short and long pointers exist, the normal string representation in C++ is always zero-terminated, and the compiler is type-safe so won't let us apply non-string operations to the string. Therefore none of this information is of any real use to a programmer - it's just more typing.
However, I use a similar idea: prefixes that clarify the usage of a variable.
The main ones are:
These can be combined, so a static member variable which is a pointer would be "mspName".
Where are these useful?
This is a simple system which adds meaningful and useful information to code, and eliminates the possibility of many simple but common programming mistakes.