language-agnostic - 为什么我不应该使用“匈牙利符号”？

Question

我知道匈牙利语指的是什么 - 提供有关变量、参数或类型的信息作为其名称的前缀。每个人似乎都强烈反对它，尽管在某些情况下这似乎是一个好主意。如果我觉得有用的信息正在被传递，为什么我不应该把它放在可以得到的地方呢？

另请参阅：人们在现实世界中使用匈牙利命名约定吗？

Answer 1

v 使用 adjHungarian 注释 v 使阅读 ncode adj 困难。

Answer 2

大多数人以错误的方式使用匈牙利符号并得到错误的结果。

阅读 Joel Spolsky 的这篇优秀文章：让错误的代码看起来是错误的。

简而言之，在变量名称前加上它们的type（字符串）（匈牙利系统）的匈牙利表示法是不好的，因为它没用。

Hungarian Notation 正如其作者所设计的那样，您在变量名称前加上它的前缀kind（使用 Joel 的示例：安全字符串或不安全字符串），所谓的 Apps Hungarian 有其用途并且仍然很有价值。

Answer 3

乔尔错了，这就是原因。

他所说的“应用程序”信息应该在类型系统中编码。您不应依赖翻转变量名称来确保不会将不安全数据传递给需要安全数据的函数。您应该将其设为类型错误，这样就不可能这样做。任何不安全的数据都应该有一个标记为不安全的类型，这样它就不能被传递给一个安全的函数。从不安全转换为安全应该需要使用某种清理功能进行处理。

乔尔所说的“种类”的很多东西都不是种类。事实上，它们是类型。

然而，大多数语言缺乏的是一种类型系统，它的表达能力足以强制执行这些区别。例如，如果 C 有一种“强 typedef”（其中 typedef 名称具有基本类型的所有操作，但不能转换为它），那么很多这些问题都会消失。例如，如果您可以说，strong typedef std::string unsafe_string;要引入一种unsafe_string无法转换为 std::string 的新类型（因此可以参与重载决议等），那么我们就不需要愚蠢的前缀。

因此，匈牙利语是针对非类型事物的核心主张是错误的。它被用于类型信息。当然，比传统的 C 类型信息更丰富的类型信息；它是对某种语义细节进行编码以指示对象用途的类型信息。但它仍然是类型信息，正确的解决方案一直是将其编码到类型系统中。将其编码到类型系统中无疑是获得正确验证和执行规则的最佳方式。变量名称根本不切实际。

换句话说，目标不应该是“让错误的代码在开发人员看来是错误的”。它应该是“让错误的代码在编译器看来是错误的”。

Answer 4

我认为它严重混淆了源代码。

在强类型语言中它也不会给你带来太多好处。如果你做了任何形式的类型不匹配错误，编译器会告诉你。

Answer 5

匈牙利符号仅在没有用户定义类型的语言中才有意义。在现代函数式或 OO 语言中，您会将有关“种类”值的信息编码到数据类型或类中，而不是变量名中。

几个答案参考了 Joels 的文章。但是请注意，他的示例使用的是 VBScript，它不支持用户定义的类（至少在很长一段时间内）。在具有用户定义类型的语言中，您可以通过创建 HtmlEncodedString 类型来解决相同的问题，然后让 Write 方法只接受它。在静态类型语言中，编译器将捕获任何编码错误，在动态类型中，您将获得运行时异常 - 但无论如何您都可以防止编写未编码的字符串。匈牙利符号只是将程序员变成了人类类型检查员，这种工作通常由软件更好地处理。

Joel 区分了“systems Hungarian”和“apps Hungarian”，其中“systems Hungarian”编码了int、float等内置类型，“Apps Hungarian”编码了“kinds”，这是更高级的元信息关于机器类型之外的变量，在 OO 或现代函数式语言中，您可以创建用户定义的类型，因此在这个意义上，类型和“种类”之间没有区别 - 两者都可以由类型系统表示 - 和“应用程序”匈牙利语与“系统”匈牙利语一样多余。

所以回答你的问题：系统匈牙利语只会在不安全的弱类型语言中有用，例如将浮点值分配给 int 变量会使系统崩溃。匈牙利符号是在 60 年代专门发明用于BCPL的，这是一种相当低级的语言，根本不做任何类型检查。我认为今天普遍使用的任何语言都没有这个问题，但这种符号作为一种货物崇拜编程而存在。

如果您使用的是没有用户定义类型的语言，例如旧版 VBScript 或早期版本的 VB，应用匈牙利语将是有意义的。也许还有 Perl 和 PHP 的早期版本。同样，在现代语言中使用它是纯粹的货物崇拜。

在任何其他语言中，匈牙利语都是丑陋、多余和脆弱的。它重复从类型系统中已知的信息，你不应该重复自己。为描述该类型特定实例的意图的变量使用描述性名称。使用类型系统来编码关于变量“种类”或“类”的不变量和元信息 - 即。类型。

Joels 文章的一般观点 - 让错误的代码看起来不正确 - 是一个非常好的原则。然而，对错误更好的保护是——在可能的情况下——让编译器自动检测到错误代码。

Answer 6

我的所有项目总是使用匈牙利符号。当我处理 100 多个不同的标识符名称时，我发现它真的很有帮助。

例如，当我调用一个需要字符串的函数时，我可以输入 's' 并点击控制空间，我的 IDE 将准确地显示以 's' 为前缀的变量名称。

另一个优点是，当我为未签名的整数添加 u 和为已签名的整数添加 i 时，我会立即看到我以潜在危险的方式混合有符号和无符号的位置。

我不记得有多少次在一个巨大的 75000 行代码库中，由于将局部变量命名为与该类的现有成员变量相同，导致错误（由我和其他人引起）。从那以后，我总是在成员前面加上'm_'

这是一个品味和经验的问题。在你尝试之前不要敲它。

Answer 7

您忘记了包含此信息的首要原因。与你无关，程序员。这与你离开公司 2 或 3 年后下路的人有关，他必须阅读那些东西。

是的，IDE 会为您快速识别类型。但是，当您阅读一些长批次的“业务规则”代码时，不必在每个变量上暂停以找出它是什么类型，这很好。当我看到诸如 strUserID、intProduct 或 guiProductID 之类的东西时，它使“加速”时间变得更加容易。

我同意 MS 在他们的一些命名约定上走得太远了——我将其归类为“太多的好东西”。

命名约定是好事，只要你坚持。我已经浏览了足够多的旧代码，这些代码让我不断地回头查看许多类似名称的变量的定义，以至于我推动了“骆驼外壳”（就像在以前的工作中所说的那样）。现在，我的工作有数千行完全没有注释的带有 VBScript 的经典 ASP 代码，而试图弄清楚事情是一场噩梦。

Answer 8

在每个变量名的开头添加神秘字符是不必要的，这表明变量名本身的描述性不够。无论如何，大多数语言在声明时都需要变量类型，因此该信息已经可用。

还有一种情况是，在维护期间，变量类型需要更改。示例：如果声明为“uint_16 u16foo”的变量需要变为 64 位无符号，则会发生以下两种情况之一：

1. 您将检查并更改每个变量名称（确保不要使用相同名称处理任何不相关的变量），或者
2. 只改类型不改名字，只会造成混乱。

Answer 9

Joel Spolsky 写了一篇很好的博客文章。 http://www.joelonsoftware.com/articles/Wrong.html 基本上，当一个像样的 IDE 会告诉您想要键入变量时，它归结为不会使您的代码更难阅读，如果您不记得的话。此外，如果您将代码划分得足够多，您就不必记住三页以上声明的变量是什么。

Answer 10

这些天范围不是比类型更重要吗，例如

* l for local
* a for argument
* m for member
* g for global
* etc

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

Answer 11

没有理由不正确使用匈牙利符号。它不受欢迎是因为长期以来一直反对滥用匈牙利符号，尤其是在 Windows API 中。

在过去的糟糕日子里，在任何类似 IDE 的 DOS 存在之前（很可能你没有足够的空闲内存来在 Windows 下运行编译器，所以你的开发是在 DOS 中完成的），你没有得到任何帮助将鼠标悬停在变量名称上。（假设您有鼠标。）您必须处理的是事件回调函数，其中所有内容都以 16 位整数 (WORD) 或 32 位整数 (LONG WORD) 的形式传递给您。然后，您必须将这些参数转换为给定事件类型的适当类型。实际上，大部分 API 几乎都是无类型的。

结果，一个具有如下参数名称的 API：

LRESULT CALLBACK WindowProc(HWND hwnd,
                            UINT uMsg,
                            WPARAM wParam,
                            LPARAM lParam);

请注意，wParam 和 lParam 的名称虽然很糟糕，但实际上并不比将它们命名为 param1 和 param2 差。

更糟糕的是，Window 3.0/3.1 有两种类型的指针，near 和 far。因此，例如，内存管理函数 LocalLock 的返回值是 PVOID，但 GlobalLock 的返回值是 LPVOID（“L”表示长）。然后，这个糟糕的符号得到扩展，以便长指针字符串以 lp为前缀，以将其与只是被 malloc 的字符串区分开来。

对这种事情的强烈反对也就不足为奇了。

Answer 12

匈牙利符号在没有编译时类型检查的语言中很有用，因为它允许开发人员快速提醒自己如何使用特定变量。它对性能或行为没有任何作用。它应该提高代码的可读性，主要是一种品味和编码风格。正是因为这个原因，它受到了许多开发人员的批评——不是每个人的大脑都有相同的接线。

对于编译时类型检查语言，它几乎是无用的——向上滚动几行应该会显示声明并因此显示类型。如果你的全局变量或你的代码块跨越了不止一个屏幕，你就会遇到严重的设计和可重用性问题。因此，批评之一是匈牙利符号允许开发人员进行糟糕的设计并轻松摆脱它。这大概是被讨厌的原因之一吧。

另一方面，在某些情况下，即使是编译时类型检查语言也会受益于匈牙利表示法——win32 API 中的void指针或HANDLE。这些混淆了实际的数据类型，在那里使用匈牙利表示法可能有好处。然而，如果可以在构建时知道数据的类型，为什么不使用适当的数据类型。

一般来说，没有理由不使用匈牙利符号。这是一个喜欢、策略和编码风格的问题。

Answer 13

作为一名 Python 程序员，Hungarian Notation 很快就崩溃了。在 Python 中，我不在乎某个东西是否是字符串——我关心它是否可以像字符串一样工作（即，它是否有一个___str___()返回字符串的方法）。

例如，假设我们有 foo 作为整数，12

foo = 12

匈牙利符号告诉我们应该称它为 iFoo 或其他东西，以表示它是一个整数，以便稍后我们知道它是什么。除了在 Python 中，这不起作用，或者更确切地说，它没有意义。在 Python 中，当我使用它时，我决定了我想要什么类型。我想要一个字符串吗？好吧，如果我这样做：

print "The current value of foo is %s" % foo

注意%s- 字符串。Foo 不是字符串，但%操作员将调用foo.___str___()并使用结果（假设它存在）。foo仍然是一个整数，但如果我们想要一个字符串，我们就把它当作一个字符串。如果我们想要一个浮点数，那么我们将它视为一个浮点数。在像 Python 这样的动态类型语言中，匈牙利表示法是没有意义的，因为在你使用它之前，它是什么类型并不重要，如果你需要一个特定的类型，那么只要确保在你使用它时将它转换为那个类型（float(foo)例如用它。

请注意，像 PHP 这样的动态语言没有这个好处——PHP 试图根据一组几乎没有人记住的晦涩规则在后台做“正确的事情”，这通常会意外地导致灾难性的混乱。在这种情况下，某种命名机制，比如$files_countor $file_name，会很方便。

在我看来，匈牙利符号就像水蛭。也许在过去它们是有用的，或者至少它们看起来很有用，但现在它只是很多额外的打字而没有太多好处。

Answer 14

IDE 应该传递这些有用的信息。当 IDE 不那么先进时，匈牙利语可能有某种意义（不是很多，而是某种意义上）。

Answer 15

匈牙利语对我来说是希腊语——以一种很好的方式

作为一名工程师，而不是程序员，我立即阅读了 Joel 关于 Apps Hungarian 优点的文章：“让错误的代码看起来是错误的”。我喜欢 Apps Hungarian，因为它模仿工程、科学和数学如何使用下标和上标符号（如希腊字母、数学运算符等）来表示方程式和公式。以牛顿万有引力定律为例：首先是标准数学符号，然后是 Apps Hungarian 伪代码：

frcGravityEarthMars = G * massEarth * massMars / norm(posEarth - posMars)

在数学符号中，最突出的符号是那些表示存储在变量中的信息种类的符号：力、质量、位置矢量等。下标起到了次要作用以澄清：什么的位​​置？这正是 Apps Hungarian 正在做的事情；它首先告诉您存储在变量中的内容类型，然后再详细说明——关于最接近的代码可以使用数学符号。

显然，强类型可以解决 Joel 文章中的安全与不安全字符串示例，但您不会为位置和速度向量定义单独的类型；两者都是大小为 3 的双数组，您可能对其中一个执行的任何操作都可能适用于另一个。此外，连接位置和速度（形成状态向量）或取它们的点积是非常有意义的，但可能不添加它们。键入如何允许前两个并禁止第二个，以及这样的系统如何扩展到您可能想要保护的每个可能的操作？除非你愿意在你的打字系统中编码所有的数学和物理。

最重要的是，许多工程都是使用弱类型的高级语言（如 Matlab）或 Fortran 77 或 Ada 等旧语言完成的。

因此，如果您有一种花哨的语言，而 IDE 和 Apps Hungarian 对您没有帮助，那就忘记它——很多人显然都有。但对我来说，比使用弱类型或动态类型语言工作的新手程序员更糟糕，我可以使用 Apps Hungarian 比不使用更快地编写更好的代码。

Answer 16

我一直认为在正确的地方有一两个前缀不会有什么坏处。我想如果我可以在那里传授一些有用的东西，比如“嘿，这是一个界面，不要指望特定的行为”，就像在 IEnumerable 中一样，我应该这样做。注释可以使事情变得混乱，而不仅仅是一两个字符的符号。

Answer 17

大多数现代 IDE 都非常冗余和无用，它们在使类型明显化方面做得很好。

另外——对我来说——看到 intI、strUserName 等很烦人 :)

Answer 18

如果我觉得有用的信息正在被传递，为什么我不应该把它放在可以得到的地方呢？

那么谁在乎别人怎么想呢？如果您觉得它有用，请使用该符号。

Answer 19

我的经验，这很糟糕，因为：

1 - 如果您需要更改变量的类型（即如果您需要将 32 位整数扩展为 64 位整数），那么您将破坏所有代码；

2 - 这是无用的信息，因为类型已经在声明中，或者您使用的是动态语言，其中实际类型首先不应该那么重要。

此外，对于接受通用编程的语言（即某些变量的类型在您编写函数时无法确定的函数）或动态类型系统（即在编译时甚至无法确定类型时），您将如何命名您的变量？并且大多数现代语言都支持其中一种，即使是一种受限制的形式。

Answer 20

在Joel Spolsky 的《让错误的代码看起来错误》中，他解释说，每个人都认为的匈牙利符号（他称之为 Systems Hungarian）并不是它的真正意图（他称之为 Apps Hungarian）。向下滚动到“我在匈牙利”标题以查看此讨论。

基本上，Systems Hungarian 一文不值。它只是告诉你编译器和/或 IDE 会告诉你的同样的事情。

Apps Hungarian 会告诉您变量的含义，并且实际上很有用。

Answer 21

如果控件列表显示在您的 IDE 中按字母顺序排列的下拉列表中，则它是用于命名表单上的控件（btnOK、txtLastName 等）的有用约定。

Answer 22

我倾向于仅将 Hungarian Notation 与 ASP.NET 服务器控件一起使用，否则我发现很难弄清楚表单上的控件是什么。

拿这个代码片段：

<asp:Label ID="lblFirstName" runat="server" Text="First Name" />
<asp:TextBox ID="txtFirstName" runat="server" />
<asp:RequiredFieldValidator ID="rfvFirstName" runat="server" ... />

如果有人可以展示一种更好的方法来获得没有匈牙利语的那组控制名称，我会很想转向它。

Answer 23

Joel 的文章很棒，但似乎忽略了一个要点：

匈牙利语使特定的“想法”（种类 + 标识符名称）在整个代码库（甚至是非常大的代码库）中唯一或接近唯一。

这对于代码维护来说是巨大的。这意味着您可以使用良好的 ol' 单行文本搜索（grep、findstr、'在所有文件中查找'）来查找每个提及该“想法”的内容。

当我们拥有知道如何阅读代码的 IDE 时，为什么这很重要？因为他们还不是很擅长。这在小型代码库中很难看到，但在大型代码库中很明显 - 当注释、XML 文件、Perl 脚本以及源代码控制之外的地方（文档、wiki、错误数据库）中可能提到“想法”时。

即使在这里，您也必须要小心一些——例如，在 C/C++ 宏中粘贴标记可以隐藏对标识符的提及。这种情况可以使用编码约定来处理，无论如何它们往往只会影响代码库中的少数标识符。

PS 关于使用类型系统与匈牙利语的区别 - 最好同时使用两者。如果编译器无法为您捕获它，您只需要错误的代码看起来就错了。在很多情况下，让编译器捕获它是不可行的。但在可行的情况下 - 是的，请改为这样做！

但是，在考虑可行性时，请考虑拆分类型的负面影响。例如，在 C# 中，用非内置类型包装“int”会产生巨大的后果。所以在某些情况下它是有意义的，但不是在所有情况下。

Answer 24

揭穿匈牙利符号的好处

• 它提供了一种区分变量的方法。

如果类型只是将一个值与另一个值区分开来，那么它只能用于将一种类型转换为另一种类型。如果您在类型之间转换的值相同，那么您很可能应该在专用于转换的函数中执行此操作。（我看到匈牙利的 VB6 遗留物在其所有方法参数上都使用字符串，仅仅是因为他们无法弄清楚如何反序列化 JSON 对象，或者正确理解如何声明或使用可为空的类型。）如果您有两个仅由匈牙利语前缀，它们不是从一个到另一个的转换，那么你需要详细说明你对它们的意图。

• 它使代码更具可读性。

我发现匈牙利符号使人们对变量名变得懒惰。他们有一些可以区分它的东西，他们觉得没有必要详细说明它的目的。这是您通常会在匈牙利注释代码与现代代码中找到的内容：sSQL 与 groupSelectSql（或者通常根本没有 sSQL，因为它们应该使用早期开发人员放入的 ORM。），sValue 与 formCollectionValue（或者通常也没有 sValue，因为它们恰好在 MVC 中并且应该使用它的模型绑定功能）、sType 与 publishSource 等。

它不可能是可读性的。我从任何给定的匈牙利 VB6 剩余物中看到的 sTemp1、sTemp2.​​..sTempN 比其他所有人的总和还要多。

• 它可以防止错误。

这将是由于数字 2，这是错误的。

Answer 25

用大师的话来说：

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

像往常一样有趣的阅读。

提取物：

“有人在某处读过 Simonyi 的论文，他在其中使用了“类型”这个词，并认为他的意思是类型，就像类，就像在类型系统中一样，就像编译器所做的类型检查一样。他没有。他解释得很仔细正是他所说的“类型”这个词的意思，但这并没有帮助。损害已经造成。”

“但 Apps Hungarian 仍然具有巨大的价值，因为它增加了代码的搭配，这使得代码更易于阅读、编写、调试和维护，最重要的是，它使错误的代码看起来不正确。”

在阅读 Joel On Software 之前，请确保您有一些时间。:)

Answer 26

几个原因：

• 任何现代 IDE 只需将鼠标悬停在变量上即可为您提供变量类型。
• 大多数类型名称都很长（想想HttpClientRequestProvider）可以合理地用作前缀。
• 类型信息没有携带正确的信息，它只是解释变量声明，而不是概述变量的用途（想想myInteger与pageSize）。

Answer 27

我不认为每个人都强烈反对它。在没有静态类型的语言中，它非常有用。当它用于提供类型中尚未包含的信息时，我绝对更喜欢它。就像在 C 中一样，char * szName表示该变量将引用一个以空字符结尾的字符串——这在 char* 中并不隐含——当然，typedef 也会有所帮助。

Joel 有一篇关于使用匈牙利语来判断变量是否是 HTML 编码的精彩文章：

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

无论如何，当它被用来传达我已经知道的信息时，我倾向于不喜欢匈牙利语。

Answer 28

当然，当 99% 的程序员都同意某件事时，就有问题了。他们同意这里的原因是因为他们中的大多数人从未正确使用过匈牙利符号。

有关详细的论点，请参阅我就该主题发表的博客文章。

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

Answer 29

我几乎是在匈牙利符号被发明的时候开始编码的，我第一次被迫在一个我讨厌它的项目中使用它。

过了一会儿，我意识到如果做得好，它确实有帮助，这些天我喜欢它。

但就像所有美好的事物一样，它必须被学习和理解，并且正确地做到这一点需要时间。

Answer 30

匈牙利符号被滥用，特别是被微软滥用，导致前缀比变量名长，并且显示它非常死板，特别是当您更改类型时（臭名昭著的 lparam/wparam，在 Win16 中具有不同的类型/大小，在 Win32 中相同）。

因此，由于这种滥用，以及它被 M$ 使用，它都被认为是无用的。

在我的工作中，我们用 Java 编写代码，但创始人来自 MFC 世界，所以使用类似的代码风格（对齐的大括号，我喜欢这个！，大写的方法名，我习惯了，前缀像 m_ 到类成员（字段), s_ 到静态成员等)。

他们说所有变量都应该有一个显示其类型的前缀（例如，BufferedReader 被命名为 brData）。这表明这是一个坏主意，因为类型可以更改但名称不跟随，或者编码人员在使用这些前缀时不一致（我什至看到 aBuffer、theProxy 等！）。

就个人而言，我选择了一些我认为有用的前缀，最重要的是 b 为布尔变量添加前缀，因为它们是我唯一允许使用类似语法的前缀if (bVar)（不使用某些值的自动转换为真或假）。当我用 C 编写代码时，我为使用 malloc 分配的变量使用了前缀，以提醒它以后应该被释放。等等。

所以，基本上，我并没有整体拒绝这个符号，而是采用了似乎适合我需要的符号。
当然，在为某个项目（工作、开源）做贡献时，我只是使用约定俗成的！

Answer 31

我认为美学方面的整个事情都被过度炒作了。如果这是最重要的事情，我们就不会称自己为开发人员，而是平面设计师。

我认为，一个重要的部分是你描述你的对象角色是什么，而不是它是什么。你不称自己为 HumanDustman，因为在另一种情况下，你不会最重要的是成为人类。

出于重构目的，它也非常重要：

public string stringUniqueKey = "ABC-12345";

如果您决定使用 GUID 而不是字符串，那么在重构所有引用代码后，您的变量名称会显得很愚蠢。

或者：

public int intAge = 20;

将其更改为浮点数，您将遇到同样的问题。等等。

Answer 32

• 他们是一个巨大的眼睛
• 您的 IDE 应该能够告诉您有关变量类型的所有信息
• 好的名称（HN 会妨碍它）应该向您传达您需要了解的有关变量的所有其他信息。

Answer 33

另请参阅您对成员变量使用哪种前缀？

Answer 34

匈牙利语不好，因为它从变量名中拿走宝贵的字符以换取什么，一些类型信息？

首先，在强类型语言中，如果你做了任何真正愚蠢的事情，编译器会警告你。

其次，如果您相信良好的模块化代码并且不在任何 1 个函数中做太多工作，那么您的变量很可能就在它们使用的代码之上声明（所以您在那里有类型）。

第三，如果你给每个指针加上 p 前缀，每个类都加上 C 前缀，你真的搞砸了你漂亮的现代 IDE 进行智能感知的能力（你知道这个功能在你输入什么类名时它会猜测你的输入，一旦它得到它是的，你可以按回车键，它会为你完成它？好吧，如果你在每个类前面加上 C，你总是至少有 1 个额外的字母要输入）......

Answer 35

我找不到链接，但我记得在某处（我同意）读到避免使用匈牙利符号会导致更好的编程风格。

当你编写程序的语句时，在调用它的方法之前你不应该考虑“这个对象是什么类型”，而应该考虑“我想用它做什么”，“发送什么消息给它”。

有点模糊的概念来解释，但我认为它有效。

例如，如果您将客户名称存储在变量 customerName 中，您不应该关心它是字符串还是其他类。更重要的是思考你想从这个对象中得到什么。你想让它打印（），getFirstName（），getLastName（），convertToString（）等吗？一旦你把它变成一个String类的实例并认为它是理所当然的，你限制了你自己和你的设计，因为你必须建立所有您在代码中其他地方需要的其他逻辑。

Answer 36

多年来，我在编程中使用匈牙利符号。除了一些视觉混乱和更改数据类型时更改前缀的任务之外，没有人能说服我。直到最近——当我不得不在同一个解决方案中结合现有的 C# 和 VB.NET 程序集时。

结果：我必须将“fltSomeVariable”传递给“sngSomeVariable”方法参数。即使作为一个同时使用 C# 和 VB.NET 编程的人，它也让我措手不及，让我停顿了片刻。（C# 和 VB.NET 有时使用不同的名称来表示相同的数据类型——例如，浮点数和单数。）

现在考虑一下：如果您创建一个可从多种语言调用的 COM 组件会怎样？VB.NET 和 C#“转换”对于 .NET 程序员来说很容易。但是使用 C++ 或 Java 开发的人呢？对于不熟悉 C++ 的 .NET 开发人员来说，“dwSomeVariable”是否意味着什么？

Answer 37

如果您不知道变量的类型而没有被告知，那么您可能无论如何都不应该弄乱它

类型也可能不是那么重要。如果您知道这些方法的作用，您可以弄清楚变量正在做什么，然后您就会知道程序在做什么

有时您可能想要它；当类型很重要并且声明不在附近或无法轻松推断类型时。但它永远不应该被视为绝对的