值得学习该惯例还是对可读性和可维护性的祸害？

解决方案

回答

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

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

如果我们阅读有关该主题的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表示字符串等。

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

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

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

回答

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

thisMethodIsPrettyCool()
this_method_is_pretty_cool()

回答

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

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

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

回答

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

诸如sValue，iCount，dAmount或者fAmount和bFlag之类的东西无处不在。

曾几何时，有这样的惯例是有充分理由的。现在，这是一种癌症。

回答

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

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

int vBox = aBottom * lVerticalSide;

写这个：

int boxVolume = bottomArea * verticalHeight;

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

同样，如果我们要编写的变量名长于变量名，则无论如何都要考虑将其重构为对象或者函数。

回答

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

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

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

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

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

回答

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

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

其他人如何处理UI元素的命名？

回答

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

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

回答

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

回答

混合标准有问题。

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

int Box = iBottom * nVerticleSide

回答

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.

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

回答

原始形式(匈牙利语右记法:))，其中前缀表示变量存储的值的类型(即长度，数量)是可以的，但并非在所有类型的应用程序中都是必需的。

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

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

回答

使用动态类型的语言时，我偶尔会使用Apps Hungarian。对于静态类型的语言，我没有。在另一个线程中查看我的解释。

回答

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

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

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

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

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

回答

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

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

回答

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

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

回答

如今，范围是否比输入更为重要，例如

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

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

回答

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

回答

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

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

• m =成员
• c =常量
• s =静态
• v =易失性
• p =指针(和pp =指向指针的指针，依此类推)
• i =索引或者迭代器

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

这些在哪里有用？

• 在用法很重要的地方，经常提醒程序员变量是(例如)易失性或者指针是一个好主意
• 一直使用指针解引用直到我使用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程序员，我并不打算使用它。但是，我有时会根据系统的大小和变量的范围将某些东西标识为数组或者对象。