人们在现实世界中使用匈牙利命名公约吗？ [关闭]
Do people use the Hungarian Naming Conventions in the real world? [closed]

考虑到大多数使用匈牙利表示法的人都在遵循它的误解版本，所以我认为这毫无意义。

如果要使用它的原始定义，可能会更有意义，但除此之外，它主要是语法糖。

如果您阅读有关该主题的Wikipedia文章 ，则会发现两个相互矛盾的符号，即系统匈牙利符号和Apps匈牙利符号 。

最初的好定义是Apps Hungarian Notation ，但大多数人都使用Systems Hungarian Notation 。

作为两者的一个示例，请考虑在变量前加上l表示长度，a表示面积，v表示体积。

使用这种表示法，以下表达式才有意义：

int vBox = aBottom * lVerticalSide;

但这不是：

int aBottom = lSide1;

如果您要混合使用前缀，则它们将被视为方程式的一部分，并且volume = area * length对于一个盒子来说不错，但是将length值复制到area变量中应该会引起一些危险。

不幸的是，其他表示法用处不大，因为人们会在变量名前加上值的类型，例如：

int iLength;
int iVolume;
int iArea;

有些人将n用作数字，将i用作整数，将f用作浮点数，将s用作字符串等。

最初的前缀原本是用来发现方程式中的问题的，但由于不必去寻找变量声明，因此它已经以某种方式转移到使代码更易于阅读的地步。 在当今的智能编辑器中，您可以将鼠标悬停在任何变量上以查找完整类型，而不仅仅是它的缩写，这种匈牙利符号已经失去了很多含义。

但是，您应该下定决心。 我只能说我都不用。

编辑只是为了添加一个简短的通知，虽然我不使用匈牙利表示法 ，但确实使用了前缀，这是下划线。 我在类的所有私有字段前加上_，否则将它们的名称拼写为属性，标题首字母大写。

正确使用《匈牙利命名公约》很有用，但不幸的是，它经常被滥用。

阅读Joel Spolsky的文章“ 使错误的代码看起来错误”，以获取适当的观点和理由。

从本质上讲，基于类型的匈牙利表示法在大多数情况下是没有用的，在变量中加上有关其类型的信息（例如，对象是字符串，句柄，整数等）都没有用，并且通常只会增加开销而几乎没有好处。 不幸的是，这是大多数人熟悉的匈牙利表示法。 但是，按预期，匈牙利表示法的目的是在变量包含的“种类”数据上添加信息。 这使您可以将其他类型的数据与其他类型的数据进行分区，除非可能通过某些转换过程，否则其他类型的数据不应混合在一起。 例如，基于像素的坐标与其他单位的坐标，或者不安全的用户输入与来自安全来源的数据等。

这样看，如果您发现自己在代码中摸索寻找变量的信息，那么您可能需要调整命名方案以包含该信息，这就是匈牙利惯例的本质。

请注意，匈牙利表示法的替代方法是使用更多的类来显示变量使用的意图，而不是在各处都依赖原始类型。 例如，对于不安全的用户输入，可以使用简单的字符串包装器类，而对于安全数据，可以使用单独的包装器类，而不是为不安全的用户输入使用变量前缀。 在强类型语言中，这具有由编译器强制进行分区的优点（即使在不强类型的语言中，您通常也可以添加自己的tripwire代码），但开销却不小。

对于UI元素，我仍然使用匈牙利表示法，其中几个UI元素与特定的对象/值相关，例如，

lblFirstName用于标签对象，txtFirstName用于文本框。 我绝对不能将它们都命名为“ FirstName”，即使这是两个对象的关注点/责任。

其他人如何命名UI元素？

它毫无意义（而且会分散注意力），但在我的公司中使用相对较多，至少对于int，string，boolean和double之类的类型而言。

喜欢的东西sValue ， iCount ， dAmount或fAmount和bFlag到处都是。

曾几何时，有此约定的充分理由。 现在，这是一种癌症。

我认为匈牙利符号是通往更具可读性的代码“路径”上有趣的脚注，并且如果操作正确，则最好不这样做。

不过，我还是想取消它，而不是这样：

int vBox = aBottom * lVerticalSide;

写这个：

int boxVolume = bottomArea * verticalHeight;

是2008年。我们不再有80个字符的固定宽度屏幕！

同样，如果您要编写的变量名要长得多，那么无论如何您都应该将其重构为对象或函数。

很抱歉跟进一个问题，但是在接口前面加上“ I”是否符合匈牙利符号？ 如果真是这样，那么是的，很多人在现实世界中使用它。 如果没有，请忽略此。

这些天范围比输入更重要吗，例如

• l对于本地
• 一个论点
• m为成员
• g代表全球
• 等等

使用现代的重构旧代码，搜索和替换符号的技术，因为您更改了符号的类型是乏味的，因此编译器将捕获类型更改，但通常不会捕获对范围的不正确使用，明智的命名约定在这里有所帮助。

我认为匈牙利书写法是一种规避我们短期记忆能力的方法。 根据心理学家的说法，我们可以存储大约7个正负2个信息块 。 通过包含前缀添加的额外信息，即使没有其他上下文，也可以通过提供有关标识符含义的更多详细信息来帮助我们。 换句话说，我们可以猜测变量的用途，而无需查看其用法或​​声明方式。 可以通过应用诸如封装和单一责任原则之类的技术来避免这种情况。

我不知道是否已经进行了经验研究。 我假设当我们尝试理解具有九个以上实例变量的类或具有九个以上局部变量的方法时，工作量会急剧增加。

当我看到匈牙利人的讨论时，我很高兴看到人们在认真思考如何使自己的代码更清晰，如何使错误更明显。 这正是我们所有人都应该做的！

但是不要忘记，除了命名之外，您还可以使用一些强大的工具。

提取方法如果方法太长了，以至于变量声明已经滚动到屏幕顶部之外，请考虑使方法更小。 （如果方法太多，请考虑使用新类。）

强类型输入如果您发现要使用存储在整数变量中的邮政编码并将其分配给鞋子尺寸的整数变量，请考虑为邮政编码创建一个类，并为鞋子尺寸创建一个类。 然后，您的错误将在编译时捕获，而无需人工进行仔细检查。 当我这样做时，我通常会发现一堆针对邮政编码和鞋子大小的逻辑，这些逻辑围绕我的代码展开，然后可以将其移至新类中。 突然我的所有代码变得更清晰，更简单，并且免受某些类的错误的影响。 哇。

总结：是的，请认真考虑如何在代码中使用名称来清楚地表达自己的想法，同时还要考虑可以调用的其他强大的OO工具。

我对匈牙利表示法的使用不十分严格，但是我发现自己经常使用它来保留一些常见的自定义对象以帮助识别它们，而且我倾向于在gui控件对象的前面加上它们的控件类型。 例如，labelFirstName，textFirstName和buttonSubmit。

混合标准有问题。

正确的是确保每个人都做同一件事。

int Box = iBottom * nVerticleSide

最初的前缀原本是用来发现方程式中的问题的，但由于不必去寻找变量声明，因此它已经以某种方式转移到使代码更易于阅读的地步。 在当今的智能编辑器中，您可以将鼠标悬停在任何变量上以查找完整类型，而不仅仅是它的缩写，这种匈牙利符号已经失去了很多含义。

我稍微改变了这个习惯，但是在没有强变量类型的JavaScript中，给类型加上前缀是很有用的。

使用动态类型的语言时，我偶尔会使用Apps Hungarian。 对于静态类型的语言，我没有。 参见我在其他主题中的解释。

我对按钮，文本框和标签等UI元素使用匈牙利语命名。 主要好处是在Visual Studio Intellisense弹出窗口中进行分组。 如果我想访问我的标签，我只需开始输入lbl ....，Visual Studio就会将我所有的标签，nicley组合在一起。

但是，在做完越来越多的Silverlight和WPF之类的事情之后，利用数据绑定，我什至不再命名所有控件，因为我不必从背后的代码中引用它们（因为实际上再也没有任何代码了） ;）

在类型安全的语言中，匈牙利表示法毫无意义。 例如，您将在旧的Microsoft代码中看到的常见前缀是“ lpsz”，这意味着“指向零终止字符串的长指针”。 自1700年代初以来，我们就没有使用短指针和长指针存在的分段式体系结构，C ++中的常规字符串表示形式始终为零终止，并且编译器是类型安全的，因此，不允许我们将非字符串操作应用于串。 因此，这些信息对程序员没有任何实际用处-只是更多的输入。

但是，我使用类似的想法：前缀，以阐明变量的用法 。 主要的是：

• m =成员
• c =常量
• s =静态
• v =挥发性
• p =指针（和pp =指向指针的指针，依此类推）
• i =索引或迭代器

这些可以组合，因此作为指针的静态成员变量将为“ mspName”。

这些在哪里有用？

• 在用法很重要的地方，最好不断提醒程序员变量是（例如）volatile或指针
• 一直使用指针解引用直到我使用p前缀。 现在，很容易知道何时有对象（橙色），指向对象的指针（pOrange）或指向对象的指针（ppOrange）。 要取消引用对象，只需在其名称前为每个p放置一个星号。 案例解决了，不再有deref错误！
• 在构造函数中，我通常会发现参数名称与成员变量的名称（例如大小）相同。 我更喜欢使用“ mSize = size;” 而不是“ size = theSize”或“ this.size = size”。 这也更加安全：当我说“ mSize = 1”（设置成员）时，我不会意外使用“ size = 1”（设置参数）
• 在循环中，我的迭代器变量都是有意义的名称。 大多数程序员使用“ i”或“ index”，然后在想要内部循环时必须组成新的无意义的名称（“ j”，“ index2”）。 我使用一个有意义的名称加上i前缀（iHospital，iWard，iPatient），因此我始终知道迭代器在迭代什么。
• 在循环中，可以通过使用具有不同前缀的相同基本名称来混合多个相关变量：Orange orange = pOrange [iOrange]; 这也意味着您不会产生数组索引错误（pApple [i]看起来不错，但是将其写为pApple [iOrange]且该错误立即显而易见）。
• 许多程序员会在不了解我的系统的情况下使用我的系统：通过添加冗长的后缀（例如“ Index”或“ Ptr”），没有充分的理由使用比单个字符恕我直言更长的格式，因此我使用“ i”和“ p”。 更少的打字，更一致，更容易阅读。

这是一个简单的系统，它将有意义的有用信息添加到代码中，并且消除了许多简单但常见的编程错误的可能性。

作为一个非常松散类型的PHP程序员，我并不打算使用它。 但是，我有时会根据系统的大小和变量的范围将某些东西标识为数组或对象。

原始形式（正确的匈牙利符号：）），其中前缀表示变量存储的值的类型（即长度，数量）是可以的，但并非在所有类型的应用程序中都是必需的。

在大多数现代编程语言中，前缀表示类型（字符串，整数）的流行形式（错误的匈牙利符号）是没有用的。

尤其是带有无意义的名称，例如strA。 我不明白我们使用的是带有长前缀的毫无意义的名称，但没有任何意义。

我对组件（例如editFirstName，lblStatus等）使用基于类型的（Systems HN），因为它可以使自动完成功能更好地工作。

我有时将App HN用于类型信息足够的变量。 即fpX指示固定的指向变量（int类型，但不能与int混合和匹配），rawInput用于未验证的用户字符串等

在过去的6个月中，我一直在IBM工作，但从未在任何地方看到它（感谢我，因为我讨厌它。）我看到的是camelCase或c_style。

thisMethodIsPrettyCool()
this_method_is_pretty_cool()

这取决于您的语言和环境。 通常，除非您所在的开发环境很难找到变量的类型，否则我不会使用它。

还有两种不同类型的匈牙利符号。 请参阅乔尔的文章。 我找不到它（他的名字并不能使它们容易找到），有人链接到我的意思吗？

编辑：楔在他的帖子中有我的意思。