当前位置： 文江博客话题详情

匈牙利表示法的好例子？

发布于 2024-07-07 19:58:51 字数 138 浏览 23 评论 0原文

这个问题是为了寻找匈牙利表示法的好例子，这样我们就可以收集这些例子。

编辑：我同意匈牙利语类型并不是那么必要，我希望有更具体的例子，它可以提高可读性和可维护性，就像乔尔在他的文章中给出的那样（根据我的回答）。

原文

This question is to seek out good examples of Hungarian Notation, so we can bring together a collection of these.

Edit: I agree that Hungarian for types isn't that necessary, I'm hoping for more specific examples where it increases readability and maintainability, like Joel gives in his article (as per my answer).

如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论， 你可以免费 注册 一个本站的账号。

评论（22）

给妤﹃绝世温柔 2024-07-14 19:58:52

我同意匈牙利表示法不再特别有用。 我认为它的初衷不是指示数据类型，而是指示实体类型。 例如，在涉及客户、员工和用户姓名的代码部分中，您可以将本地字符串变量命名为 cusName、empName 和 usrName。 这将有助于区分听起来相似的变量名称。 整个应用程序将使用相同的实体前缀。 但是，当使用 OO 并且处理对象时，这些前缀在 Customer.Name、Employee.Name 和 User.Name 中是多余的。

I agree that Hungarian notation is no longer particularly useful. I thought that its original intention was to indicate not datatype, but rather entity type. In a code section involving the names of customers, employees and the user, for example, you could name local string variables cusName, empName and usrName. That would help distinguish among similar-sounding variable names. The same prefixes for the entities would be used throughout the application. However, when OO is used, and you're dealing with objects, those prefixes are redundant in Customer.Name, Employee.Name and User.Name.

回复 原文
逆光下的微笑 2024-07-14 19:58:52

变量的名称应该描述它是什么。良好的变量命名使匈牙利表示法毫无用处。

但是，有时除了良好的变量命名之外，您还会使用匈牙利表示法。 m_numObjects 有两个“前缀”：m_ 和 num。 m_ 表示范围：它是与this 绑定的数据成员。 num 表示值是什么。

当我阅读“好的”代码时，即使它确实包含一些“匈牙利语”，我也不会感到受到阻碍。 右：我阅读代码，但不点击它。 （事实上​​，我在编码时几乎不使用鼠标，或任何巫毒编程特定的查找功能。）

当我阅读 m_ubScale 之类的东西时，我的速度变慢了（是的，我在看着你，Liran！），因为我必须查看它的用法（没有评论！）以找出它的缩放比例（如果有的话？）和它的数据类型（恰好是定点字符）。 更好的名称是 m_scaleFactor 或 m_zoomFactor，带有定点数的注释，甚至是 typedef。 （事实上​​， typedef 会很有用，因为几个类的其他几个成员使用相同的定点格式。但是，有些不使用，但仍然标记为 m_ubWhatever！至少可以说，令人困惑。

）认为匈牙利语是变量名称的补充，而不是信息的替代品。 而且，很多时候匈牙利表示法根本不会增加变量的可读性，浪费字节和读取时间。

只是我的2美分。

The name of the variable should describe what it is. Good variable naming makes Hungarian notation useless.

However, sometimes you'd use Hungarian notation in addition to good variable naming. m_numObjects has two "prefixes:" m_ and num. m_ indicates the scope: it's a data member tied to this. num indicates what the value is.

I don't feel hindered at all when I read "good" code, even if it does contain some "Hungarian." Right: I read code, I don't click it. (In fact, I hardly use my mouse ever when coding, or any voodoo programming-specific lookup features.)

I am slowed when I read things like m_ubScale (yes, I'm looking at you, Liran!), as I have to look at its usage (no comments!) to find out what it scales (if at all?) and it's datatype (which happens to be a fixed-point char). A better name would be m_scaleFactor or m_zoomFactor, with a comment as a fixed-point number, or even a typedef. (In fact, a typedef would be useful, as there are several other members of several classes which use the same fixed-point format. However, some don't, but are still labeled m_ubWhatever! Confusing, to say the least.)

I think Hungarian was meant to be an additive to the variable name, not a replacement for information. Also, many times Hungarian notation adds nothing at all to the variable's readability, wasting bytes and read time.

Just my 2¢.

回复 原文
帝王念 2024-07-14 19:58:52

没有匈牙利表示法的好例子。 只是不要使用它。 即使您使用的是弱类型语言也不会。 你会生活得更幸福。

但如果你真的需要一些理由不使用它，这是我最喜欢的一个，摘自这个很棒的链接< /a>:

匈牙利表示法中的一个后续技巧是“更改变量的类型但保持变量名称不变”。 这几乎总是在 Windows 应用程序中完成，从 Win16 迁移到 Win32 WndProc(HWND hW, UINT wMsg, WPARAM wParam, LPARAM lParam)，其中 w 值提示它们是单词，但它们实际上指的是 long。 这种方法的真正价值随着 Win64 迁移而显现出来，此时参数将是 64 位宽，但旧的“w”和“l”前缀将永远保留。

There's no such thing as a good example of hungarian notation. Just don't use it. Not even if you are using a weakly typed language. You'll live happier.

But if you really need some reason not to use it, this is my favourite one, extracted from this great link:

One followon trick in the Hungarian notation is "change the type of a variable but leave the variable name unchanged". This is almost invariably done in windows apps with the migration from Win16 :- WndProc(HWND hW, WORD wMsg, WORD wParam, LONG lParam) to Win32 WndProc(HWND hW, UINT wMsg, WPARAM wParam, LPARAM lParam) where the w values hint that they are words, but they really refer to longs. The real value of this approach comes clear with the Win64 migration, when the parameters will be 64 bits wide, but the old "w" and "l" prefixes will remain forever.

回复 原文
泪眸﹌ 2024-07-14 19:58:52

我发现自己使用表示“工作”的“w”作为前缀，而不是“temp”或“tmp”，用于仅用于操纵数据的局部变量，例如：

Public Function ArrayFromDJRange(rangename As Range, slots As Integer) As Variant

' this function copies a Disjoint Range of specified size into a Variant Array 7/8/09 ljr

Dim j As Integer
Dim wArray As Variant
Dim rCell As Range

wArray = rangename.Value ' to initialize the working Array
ReDim wArray(0, slots - 1) ' set to size of range
j = 0

For Each rCell In rangename
    wArray(0, j) = rCell.Value
    j = j + 1
Next rCell

ArrayFromDJRange = wArray

End Function

I find myself using 'w' meaning 'working', as a prefix instead of 'temp' or 'tmp', for local variables that are just there to jockey data around, like:

Public Function ArrayFromDJRange(rangename As Range, slots As Integer) As Variant

' this function copies a Disjoint Range of specified size into a Variant Array 7/8/09 ljr

Dim j As Integer
Dim wArray As Variant
Dim rCell As Range

wArray = rangename.Value ' to initialize the working Array
ReDim wArray(0, slots - 1) ' set to size of range
j = 0

For Each rCell In rangename
    wArray(0, j) = rCell.Value
    j = j + 1
Next rCell

ArrayFromDJRange = wArray

End Function
回复 原文
剧终人散尽 2024-07-14 19:58:51

要求匈牙利表示法的好例子的问题在于，每个人都会对好例子有自己的想法。 我个人的观点是，最好的匈牙利表示法是没有匈牙利语符号。 该表示法最初旨在表示变量的预期用途而不是其类型，但它通常用于类型信息，特别是对于表单控件（例如，txtFirstName用于文本某人名字的方框。）。 这使得代码在可读性（例如，“prepIn nounTerms prepOf nounReadability”）和需要更改类型时的重构（Win32 API 中的“lParams”已更改类型）方面的可维护性较差。

您可能应该考虑根本不使用它。 示例：

  • strFirstName - 这可以是 firstName，因为它的用途很明显，类型并不那么重要，在这种情况下应该很明显。 如果不明显，IDE 可以帮助您。
  • txtFirstName - 可以更改为 FirstNameTextBox 或 FirstName_TextBox。 它读起来更好，而且您知道它是一个控件而不仅仅是文本。
  • CAccount - C 用于 MFC 中的类名，但您确实不需要它。 帐户就足够了。 大写名称是类型的标准约定（它们仅出现在特定位置，因此不会与属性或方法混淆）
  • ixArray（数组的索引）- ix 有点晦涩难懂。 尝试arrayIndex。
  • usState（State 的不安全字符串）- 看起来像“US State”。 最好选择 state_UnsafeString 之类的。 甚至可能将其包装在 UnsafeString 类中，至少使其类型安全。

The problem with asking for good examples of Hungarian Notation is that everyone's going to have their own idea of what a good example looks like. My personal opinion is that the best Hungarian Notation is no Hungarian Notation. The notation was originally meant to denote the intended usage of a variable rather than its type but it's usually used for type information, particularly for Form controls (e.g., txtFirstName for a text box for someone's first name.). This makes the code less maintainable, in terms of readability (e.g., "prepIn nounTerms prepOf nounReadability") and refactoring for when the type needs to be changed (there are "lParams" in the Win32 API that have changed type).

You should probably consider not using it at all. Examples:

  • strFirstName - this can just be firstName since it's obvious what it's for, the type isn't that important and should be obvious in this case. If not obvious, the IDE can help you with that.
  • txtFirstName - this can change to FirstNameTextBox or FirstName_TextBox. It reads better and you know it's a control and not just the text.
  • CAccount - C was used for class names in MFC but you really don't need it. Account is good enough. The uppercase name is the standard convention for types (and they only appear in specific places so they won't get confused with properties or methods)
  • ixArray (index to array) - ix is a bit obscure. Try arrayIndex.
  • usState (unsafe string for State) - looks like "U.S. State". Better go with state_UnsafeString or something. Maybe even wrap it in an UnsafeString class to at least make it type-safe.
回复 原文
爱你是孤单的心事 2024-07-14 19:58:51

正如其他匈牙利帖子中提到的，现在的经典文章来自 Joel 的网站：

http:// www.joelonsoftware.com/articles/Wrong.html

The now classic article, as mentioned in other Hungarian posts, is the one from Joel's site:

http://www.joelonsoftware.com/articles/Wrong.html

回复 原文
挽清梦 2024-07-14 19:58:51

p

（指针）。 它几乎是我使用的唯一前缀。 我认为它为变量添加了很多（例如，它是一个指针），因此应该更加尊重地对待。

匈牙利语表示数据类型有点过时了，现在 IDE 可以告诉您类型是什么（只需将鼠标悬停在变量名称上几秒钟），因此它并不那么重要。 但是，将指针视为其数据不好，因此您要确保用户清楚它是什么，即使他在编码时做出了不应该做出的假设。

p

(for pointer). Its pretty much the only prefix I use. I think it adds a lot to a variable (eg that its a pointer) and so should be treated a little more respectfully.

Hungarian for datatypes is somewhat passe now IDEs can tell you what the type is (in only a few seconds hovering over the variable name), so its not so important. But treating a pointer as if its data is not good, so you want to make sure it's obvious to the user what it is even if he makes assumptions he shouldn't when coding.

回复 原文
眉黛浅 2024-07-14 19:58:51

t

受污染的数据。 为来自不受信任来源的所有数据添加前缀，以使该变量受到污染。 在对其进行任何实际工作之前，应清除所有受污染的数据。

t

Tainted data. Prefix all data incoming from an untrusted source to make that variable as tainted. All tainted data should be cleansed before any real work is done on it.

回复 原文
吻风 2024-07-14 19:58:51

使用匈牙利语来指示类型是没有意义的，因为编译器已经为您完成了。

匈牙利语的有用之处在于区分具有相同原始类型的逻辑上不同类型的变量。 例如，如果您使用整数来表示坐标，则可以在 x 坐标前添加 x，在 y 坐标前添加 y，在距离前添加 d。 因此，您的代码将类似于

dxHighlight = xStart - xEnd

yHighlight = yLocation + 3

yEnd = yStart + dyHeight

dyCode = dyField * 2

等等。 它很有用，因为您一眼就能发现错误：如果您在 ay 上添加 dy，您总是会得到 y。 如果你减去两个 x，你总是得到一个 dx。 如果将 dy 乘以标量，则始终会得到 dy。 等等。 这样的行，

如果您看到像yTop = dyText + xButton

您一眼就知道它是错误的，因为添加 dy 和 ax 没有意义。 编译器无法为您捕捉到这一点，因为据它所知，您正在将一个 int 添加到一个 int 中，这很好。

It's pointless to use Hungarian to indicate types because the compiler already does it for you.

Where Hungarian is useful is to distinguish between logically different sorts of variables that have the same raw type. For example, if you are using ints to represent coordinates, you could prefix x coordinates with x, y coordinates with y and distances with d. So you would have code that looks like

dxHighlight = xStart - xEnd

yHighlight = yLocation + 3

yEnd = yStart + dyHeight

dyCode = dyField * 2

and so on. It's useful because you can spot errors at a glance: If you add a dy to a y, you always get a y. If you subtract two x's you always get a dx. If you multiply a dy by a scalar, you always get a dy. And so on. If you see a line like

yTop = dyText + xButton

you know at a glance that it is wrong because adding a dy and a x does not make sense. The compiler could not catch this for you because as far as it can tell, you are adding an int to an int which is fine.

回复 原文
牵你的手，一向走下去 2024-07-14 19:58:51

不要使用特定于语言的前缀。

我们使用：

n: Number 
p: Percentage 1=100% (for interest rates etc)
c: Currency
s: String
d: date
e: enumeration
o: object (Customer oCustomer=new Customer();)
...

我们对所有语言使用相同的系统：

SQL
C
C#
Javascript
VB6
VB.net
...

它是一个救星。

Do not use language specific prefixes.

We use:

n: Number 
p: Percentage 1=100% (for interest rates etc)
c: Currency
s: String
d: date
e: enumeration
o: object (Customer oCustomer=new Customer();)
...

We use the same system for all languages:

SQL
C
C#
Javascript
VB6
VB.net
...

It is a life saver.

回复 原文
原野 2024-07-14 19:58:51

我强烈反对匈牙利表示法，直到我真正开始阅读它并试图理解它的初衷。
在阅读了 Joels 的文章“错误”和文章“重新发现匈牙利表示法”后，我真的改变了主意。 如果做得正确的话，我相信它一定非常强大。

乔尔·斯波尔斯基错了
http://www.joelonsoftware.com/articles/Wrong.html

重新发现匈牙利表示法< br>
http://codingthriller.blogspot.com/2007/11/rediscovering-hungarian -notation.html

我相信大多数反对者从未真正尝试过它，也没有真正理解它。
我很想在实际项目中尝试一下。

I was strongly against Hungarian notation until I really started reading about it and trying to understand it's original intent.
After reading Joels post "Wrong" and the article "Rediscovering Hungarian Notation" I really changed my mind. Done correct I belive it must be extremly powerful.

Wrong by Joel Spolsky
http://www.joelonsoftware.com/articles/Wrong.html

Rediscovering Hungarian Notation
http://codingthriller.blogspot.com/2007/11/rediscovering-hungarian-notation.html

I belive that most Naysayers have never tried it for real and do not truly understand it.
I would love to try it out in a real project.

回复 原文
你的他你的她 2024-07-14 19:58:51

Devil's Advocate：匈牙利表示法最好的例子就是不要使用它。 :D

我们在现代 IDE 中使用匈牙利表示法并没有获得任何优势，因为它们知道类型。 它在重构变量的类型时增加了工作量，因为名称也必须更改（并且大多数时候，当您处理变量时，您无论如何都知道它是什么类型）。

您还可以使用符号来解决排序问题。 如果您使用 p 表示指针，a 表示地址，您将变量称为 apStreet 还是 paStreet？ 当你没有一致性时，可读性就会降低，并且当你必须记住书写符号的顺序时，你必须占用宝贵的思维空间。

Devil's Advocate: The best example of Hungarian notation is not to use it. :D

We do not gain any advantage to using Hungarian notation with modern IDEs because they know the type. It adds work when refactoring a type for a variable since the name would also have to be changed (and most of the time when you are dealing with a variable you know what type it is anyway).

You can also get into ordering issues with the notation. If you use p for pointer and a for address do you call your variable apStreet or paStreet? Readability is diminished when you don't have consistency, and you have to use up valuable mind space when you have to remember the order that you have to write the notation in.

回复 原文
倚栏听风 2024-07-14 19:58:51

我发现匈牙利表示法有时在动态语言中很有用。 我特别想到服务器端 Actionscript（本质上只是 javascript），但它也可以应用于其他地方。 由于根本没有真正的类型信息，匈牙利表示法有时可以帮助使事情更容易理解。

I find hungarian notation can sometimes be useful in dynamic languages. I'm specifically thinking of Server Side Actionscript (essentially just javascript), but it could apply elsewhere. Since there's no real type information at all, hungarian notation can sometimes help make things a bit easier to understand.

回复 原文
乖乖公主 2024-07-14 19:58:51

当您继承一个软件项目时，匈牙利表示法（驼峰命名法，据我所知）是非常宝贵的。

是的，您可以使用 IDE 将“鼠标悬停”在变量上并找出它是什么类，但如果您正在翻阅数千行代码，您不希望必须停下来那几秒钟 - 每... .. 一次.... 时间...

请记住 - 您不是为您或您的团队单独编写代码。 您还为那些必须在 2-5 年后学习此代码并对其进行增强的人编写它。

Hungarian notation (camel casing, as I learned it) is invaluable when you're inheriting a software project.

Yes, you can 'hover' over a variable with your IDE and find out what class it is, but if you're paging through several thousand lines of code you don't want to have to stop for those few seconds - every.... single.... time....

Remember - you're not writing code for you or your team alone. You're also writing it for the person who has to pick up this code 2-5 years down the road and enhance it.

回复 原文
唐婉 2024-07-14 19:58:51

我认为从上面链接的 Joel 的文章和一般的匈牙利表示法中学到的关键是，当变量存在不明显的情况时使用它。

文章中的一个例子是编码字符串与非编码字符串，这并不是说您应该使用匈牙利语“us”表示不安全字符串，使用“s”表示安全字符串，而是您应该有一些标识符来指示字符串是否安全。 如果它成为标准，那么就很容易看出标准何时被打破。

I think the key thing to take away from Joel's article, linked above, and Hungarian Notation in general, is to use it when there's something non-obvious about the variable.

One example, from the article, is encoded vs non encoded strings, it's not that you should use hungarian 'us' for unsafe strings and 's' for safe strings, it's that you should have some identifier to indicate that a string is either safe or not. If it becomes standard, it becomes easy to see when the standard is being broken.

回复 原文
番薯 2024-07-14 19:58:51

唯一真正有用的匈牙利语是用于成员变量的 m_。 （我还使用 sm_ 表示静态成员，因为这是仍然存在的“其他”作用域。）对于采用 80 亿字符长变量名称的宽屏监视器和编译器，缩写类型名称是不值得的。

The only Hungarian that's really useful anymore is m_ for member variables. (I also use sm_ for static members, because that's the "other" scope that still exists.) With widescreen monitors and compilers that take eight-billion-character-long variable names, abbreviating type names just isn't worth it.

回复 原文
时间海 2024-07-14 19:58:51

m

当使用 ORM（例如 hibernate）时，您倾向于处理托管和非托管对象。 更改托管对象将反映在数据库中，而无需调用显式保存，而处理托管对象则需要显式保存调用。 根据对象的不同，您处理对象的方式也会有所不同。

m

When using an ORM (such as hibernate) you tend to deal managed and unmanaged objects. Changing an managed object will be reflected in the database without calling an explicit save, while dealing with a managaged object requires an explicit save call. How you deal with the object will be different depending on which it is.

回复 原文
放赐 2024-07-14 19:58:51

我发现唯一有用的一点是在声明界面控件时，txtUsername、txtPassword、ddlBirthMonth。 它并不完美，但它对大型表单/项目很有帮助。

我不将它用于变量或其他项目，仅用于控件。

I find that the only helpful point is when declaring interface controls, txtUsername, txtPassword, ddlBirthMonth. It isn't perfect, but it helps on large forms/projects.

I don't use it for variables or other items, just controls.

回复 原文
情未る 2024-07-14 19:58:51

除了使用“p”作为指针之外，我还喜欢使用“cb”和“cch”来指示缓冲区大小参数（或变量）是字节数还是字符数（我还看到 -很少 - 'ce' 用于指示元素计数）。 因此，前缀不是传达类型，而是传达用途或意图。

我承认，我没有像我应该的那样一致地使用前缀，但我喜欢这个想法。

In addition to using 'p' for pointer, I like the idea of using 'cb' and 'cch' to indicate whether a buffer size parameter (or variable) is a count of bytes or a character count (I've also seen - rarely - 'ce' used to indicate a count of elements). So instead of conveying type, the prefix conveys use or intent.

I admit, I don't use the prefix as consistently as I probably should, but I like the idea.

回复 原文
耀眼的星火 2024-07-14 19:58:51

这是一个非常古老的问题，但这里有一些我经常使用的“匈牙利”前缀：

我的

对于局部变量，用于区分名称在全局上下文中可能有意义的位置。 如果您看到 myFoo，则它仅在此函数中使用，无论我们在其他任何地方对 Foos 执行什么操作。

myStart = GetTime();
doComplicatedOperations();
print (GetTime() - myStart);

和

tmp

用于循环或多步操作中值的临时副本。 如果您看到两个 tmpFoo 变量彼此之间的距离超过几行，那么它们几乎肯定是不相关的。

tmpX = X; 
tmpY = Y;
X = someCalc(tmpX, tmpY);
Y = otherCalc(tmpX, tmpY);

有时 old 和 new 出于与 tmp 类似的原因，通常在较长的循环或函数中。

A very old question, but here's a couple of "Hungarian" prefixes I use regularly:

my

for local variables, to distinguish locality where the name might make sense in a global context. If you see myFoo, it's only used in this function, regardless of anything else we do with Foos anywhere else.

myStart = GetTime();
doComplicatedOperations();
print (GetTime() - myStart);

and

tmp

for temporary copies of values in loops or multi-step operations. If you see two tmpFoo variables more than a couple of lines from each other, they're almost certainly unrelated.

tmpX = X; 
tmpY = Y;
X = someCalc(tmpX, tmpY);
Y = otherCalc(tmpX, tmpY);

and sometimes old and new in for similar reasons to tmp, usually in longer loops or functions.

回复 原文
梦境 2024-07-14 19:58:51

嗯，我只将它与窗口控制变量一起使用。 我使用 btn_、txt_、lbl_ 等来发现它们。 我还发现通过键入控件的类型（btn_ 等）来查找控件的名称很有帮助。

Well, I use it only with window control variables. I use btn_, txt_, lbl_ etc to spot them. I also find it helpful to look up the control's name by typing its type (btn_ etc).

回复 原文
夏花。依旧 2024-07-14 19:58:51

我只使用 p 作为指针，仅此而已。 这只是当我使用 C++ 时。 在 C# 中，我不使用任何匈牙利表示法。
例如，

MyClass myClass;
MyClass* pMyClass;

仅此而已:)

编辑：哦，我刚刚意识到这是一个谎言。 我也使用“m_”作为成员变量。 例如

class
{
private:
bool m_myVar;
}

I only ever use p for a pointer, and that's it. And that's only if I'm in C++. In C# I don't use any hungarian notation.
e.g.

MyClass myClass;
MyClass* pMyClass;

That's all :)

Edit: Oh, I just realised that's a lie. I use "m_" for member variables too. e.g.

class
{
private:
bool m_myVar;
}
回复 原文
~没有更多了~

关于作者

三生殊途

暂无简介

文章
评论
23 人气
发私信

相关话题

更多

热门标签

操作系统 程序设计 IT运维 Linux系统管理 JavaScript 服务器应用 solaris C/C++ PHP Shell BSD Vue.js aix Oracle Python HTML 系统管理 HTML5 CSS 前端
更多

推荐作者

寻梦旅人

文章 0 评论 0

冰美式不加糖

文章 0 评论 0

m0_51416705

文章 0 评论 0

123456wqwqwq

文章 0 评论 0

qq_R47skh

文章 0 评论 0

hs1283

文章 0 评论 0

更多

友情链接

文江博客
    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
    原文