为什么我不能用“匈牙利命名法”？

我认为它严重混乱的源代码。

在强类型语言中，它也没有多大帮助。如果你做了任何形式的类型不匹配的蠢事，编译器会告诉你。

IDE 应该传递有用的信息。匈牙利语可能有某种意义(不是很多，而是某种意义) ，当 IDE 还没有那么先进的时候。

Joel Spolsky 就此写了一篇很好的博文。 Http://www.joelonsoftware.com/articles/wrong.html 基本上，当一个好的 IDE 告诉你，如果你不记得变量是什么，它不会让你的代码更难读。此外，如果您使您的代码划分得足够清楚，您就不必记住在三页之上声明了什么变量。

• 它们太碍眼了
• Your IDE should be able to tell you all you need to know about a variable's type
• 好的名字(这是 HN 的障碍)应该告诉你关于变量的其他所有你需要知道的信息。

我一直认为在正确的地方加一两个前缀不会有什么坏处。我认为如果我可以传递一些有用的东西，比如“嘿，这是一个接口，不要指望特定的行为”，就在这里，就像在 IEnumable 中一样，我应该这样做。注释不仅仅是一个或两个字符符号，它还会使事情变得杂乱无章。

大多数现代 IDE 都是令人难以置信的冗余和无用的，它们在显示类型方面做得很好。

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

我不认为每个人都疯狂地反对它。在没有静态类型的语言中，它非常有用。当它用于提供类型中没有的信息时，我当然更喜欢它。与 C 类似，Char * szName表示变量将引用以 null 结尾的字符串—— char * 中没有隐含这一点——当然，typedef 也会有所帮助。

Joel 有一篇很棒的文章，是关于如何使用匈牙利语来判断一个变量是否是 HTML 编码的:

Http://www.joelonsoftware.com/articles/wrong.html

不管怎么说，我不喜欢匈牙利语当它被用来传递我已经知道的信息的时候。

用大师的话说:

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

和往常一样，读起来很有趣。

摘录:

"Somebody, somewhere, read Simonyi’s paper, where he used the word “type,” and thought he meant type, like class, like in a type system, like the type checking that the compiler does. He did not. He explained very carefully exactly what he meant by the word “type,” but it didn’t help. The damage was done."

但匈牙利应用程序仍然有巨大的价值，因为它增加了代码的搭配，使代码更容易阅读、编写、调试和维护，最重要的是，它使错误的代码看起来是错误的。”

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

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

那么谁在乎别人怎么想呢? 如果你觉得它有用，就用符号吧。

我的经验告诉我，这很糟糕，因为:

1-如果你需要改变一个变量的类型(例如，如果你需要将一个32位整数扩展为一个64位整数) ，那么你就需要破坏所有的代码;

2 - this is useless information as the type is either already in the declaration or you use a dynamic language where the actual type should not be so important in the first place.

此外，如果一种语言接受泛型(即某些变量的类型在编写函数时无法确定) ，或者使用动态类型系统(即在编译时甚至无法确定类型) ，你会如何命名变量？而且大多数现代语言都支持这两种语言中的一种，即使是以一种受限制的形式。

大多数人使用匈牙利命名法的方式错误，结果也是错误的。

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

简而言之，在变量名前面加上匈牙利命名法字符串 type(系统匈牙利语)是不好的，因为它没有用处。

这个匈牙利命名法是作者想要的，你可以在变量名前面加上它的 kind(用 Joel 的例子: 安全字符串或不安全字符串) ，所以称之为“应用匈牙利”有它的用途，并且仍然很有价值。

有几个原因:

• 任何现代的 IDE 都可以通过将鼠标悬停在变量上来提供变量类型。
• 大多数类型名称都很长(想想 HttpClientRequestProvider) ，不宜作为前缀使用。
• The type information does not carry the right information, it is just paraphrasing the variable declaration, instead of outlining the 目的 of the variable (think 我的整数 vs. 页面大小).

参见 What kind of prefix do you use for member variables?

匈牙利命名法在不需要编译时类型检查的语言中非常有用，因为它允许开发人员快速提醒自己特定变量是如何使用的。它对性能和行为没有任何影响。它被认为可以提高代码的可读性，主要是一种口味和编码风格的问题。正是因为这个原因，它受到许多开发人员的批评——不是每个人的大脑都有相同的连接。

For the compile-time type-checking languages it is mostly useless -- scrolling up a few lines should reveal the declaration and thus type. If you global variables or your code block spans for much more than one screen, you have grave design and reusability issues. Thus one of the criticisms is that Hungarian Notation allows developers to have bad design and easily get away with it. This is probably one of the reasons for hatered.

On the other hand, there can be cases where even compile-time type-checking languages would benefit from Hungarian Notation -- 无效 pointers or 把手's in win32 API. These obfuscates the actual data type, and there might be a merit to use Hungarian Notation there. Yet, if one can know the type of data at build time, why not to use the appropriate data type.

In general, there are no hard reasons not to use Hungarian Notation. It is a matter of likes, policies, and coding style.

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

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

1. You'll go through and change each variable name (making sure not to hose any unrelated variables with the same name), or
2. 只改变类型而不改变名称，这只会导致混淆。

In Joel Spolsky 让错误的代码看起来错误 he explains that what everybody thinks of as Hungarian Notation (which he calls Systems Hungarian) is not what was it was really intended to be (what he calls Apps Hungarian). Scroll down to the 我是匈牙利人 heading to see this discussion.

基本上，Systems匈牙利语是没有价值的，它只是告诉你你的编译器和/或 IDE 会告诉你同样的事情。

Apps Hungarian tells you what the variable is supposed to mean, and can actually be useful.

这种匈牙利命名法被滥用，特别是被微软滥用，导致前缀比变量名更长，并且显示它非常僵硬，特别是当你改变类型时(臭名昭著的 lparam/wparam，在 Win16中不同类型/大小，在 Win32中相同)。

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

在我的工作中，我们用 Java 编写代码，但是创始人来自 MFC 世界，所以使用类似的代码风格(对齐的大括号，我喜欢这个！方法名称的大写字母，我已经习惯了，前缀如 m _ to class member (fields) ，s _ to static member，等等。

并且他们说所有的变量都应该有一个前缀来显示它的类型(例如 BufferedReader 被命名为 brData)。这显示为一个坏主意，因为类型可以改变，但名称不遵循，或编码器不一致使用这些前缀(我甚至看到缓冲区，代理，等等!).

就个人而言，我选择了一些我认为有用的前缀，最重要的是 b 作为布尔变量的前缀，因为它们是唯一允许像 if (bVar)这样的语法的前缀(不使用自动转换某些值为 true 或 false)。 在用 C 编写代码时，我使用了一个前缀来表示用 malloc 分配的变量，以提醒它稍后应该被释放。等等。

所以，基本上，我不会拒绝这个符号作为一个整体，而是选择适合我需要的符号。
当然，在为一些项目(工作，开源)做贡献时，我只是在适当的地方使用约定！

Hungarian notation only makes sense in languages 没有用户定义的类型. In a modern functional or OO-language, you would encode information about the "kind" of value into the datatype or class rather than into the variable name.

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

Joel 区分了“系统匈牙利语”和“应用匈牙利语”，其中“系统匈牙利语”编码内置类型，如 int、 float 等，而“应用匈牙利语”编码“ kind”，这是关于机器类型之外的变量的更高级元信息。在面向对象或现代函数语言中，你可以创建用户定义的类型，所以在这个意义上，类型和“ kind”没有区别——两者都可以用类型系统来表示——而“应用匈牙利语”和“系统匈牙利语”一样多余。

所以回答你的问题: 匈牙利系统只有在不安全的弱类型语言中才有用，例如，将 float 值赋给 int 变量会导致系统崩溃。匈牙利命名法是在六十年代专门发明的，用于 BCPL，一种非常低级的语言，根本不做任何类型检查。我认为当今通用的任何语言都没有这个问题，但是符号作为一种 货物崇拜编程继续存在着。

应用程序匈牙利 将有意义，如果你使用的语言没有用户定义的类型，如旧版 VBScript 或 VB 的早期版本。也许还有 Perl 和 PHP 的早期版本。再说一次，用现代语言来使用它是纯粹的货物崇拜。

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

Joels 文章的一般观点——让错误的代码看起来是错误的——是一个非常好的原则。然而，一个更好的防止 bug 的方法是——尽可能地——编译器自动检测到错误代码。

使用匈牙利语注释使阅读 ncode 变得困难。

匈牙利语是不好的，因为它从变量名中去掉了一些珍贵的字符来交换什么，一些类型信息吗？

首先，在强类型语言中，编译器会警告你如果你真的做了什么蠢事。

Second, if you believe in good modularized code and don't do too much work in any 1 function, you're variables are probable declared just above the code they are used in anyway (so you have the type right there).

Third, if you prefix every pointer with p and every class with C, your really screwing up your nice modern IDE's ability to do intellisense (you know that feature where it guesses as you type what class name your typing and as soon as it gets it right you can hit enter and it completes it for you? well, if you prefix every class with C, you always have at least 1 extra letter to type)...

我认为 美学方面被夸大了的整个事情。如果这是最重要的事情，我们不会称自己为 开发商，而是图形 designers。

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

对于重构而言，它也非常重要:

public string stringUniqueKey = "ABC-12345";

What if you decide to use a GUID instead of a string, your variable name would look stupid after refactoring all refering code.

或者:

public int intAge = 20;

把这个变成一个浮点数，你也会遇到同样的问题，以此类推。

你没有理由不使用匈牙利命名法。它之所以不受欢迎，是因为长期以来人们一直反对匈牙利命名法的 滥用，尤其是在 Windows API 中。

In the bad-old days, before anything resembling an IDE existed for DOS (odds are you didn't have enough free memory to run the compiler under Windows, so your development was done in DOS), you didn't get any help from hovering your mouse over a variable name. (Assuming you had a mouse.) What did you did have to deal with were event callback functions in which everything was passed to you as either a 16-bit int (WORD) or 32-bit int (LONG WORD). You then had to cast those parameter to the appropriate types for the given event type. In effect, much of the API was virtually type-less.

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

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

请注意，名称 wParam 和 lParam 尽管非常糟糕，但实际上并不比命名为 param1和 param2更糟糕。

更糟糕的是，Window 3.0/3.1有两种类型的指针，近指针和远指针。例如，内存管理函数 LocalLock 的返回值是一个 PVOID，但 GlobalLock 的返回值是一个 LPVOID (长度为‘ L’)。这个糟糕的符号随后被扩展，使得一个 我ong Pointer 字符串被加上了 叶问的前缀，以便将它与一个只是被 malloc 化的字符串区分开来。

毫不奇怪，这种事情会引起强烈反对。

如果控件列表显示在 IDE 中按字母顺序排列的下拉列表中，那么对于命名窗体(btnOK、 txtLastName 等)上的控件来说，这是一个非常有用的约定。

Joel is wrong, and here is why.

That "application" information he's talking about 应该在类型系统中进行编码. You should not depend on flipping variable names to make sure you don't pass unsafe data to functions requiring safe data. You should make it a type error, so that it is 不可能 to do so. Any unsafe data should have a type that is marked unsafe, so that it simply cannot be passed to a safe function. To convert from unsafe to safe should require processing with some kind of a sanitize function.

Joel 所说的很多“种类”并不是种类，事实上，它们是种类。

然而，大多数语言都缺少一个足够具有表现力的类型系统来强制执行这种区分。例如，如果 C 有一种“ strong typedef”(其中 typedef 名称包含基类型的所有操作，但不能转换为基类型) ，那么许多这样的问题就会消失。例如，如果你可以说，strong typedef std::string unsafe_string;引入了一个新的类型 unsafe_string，它不能被转换成 std: : string (因此可以参与重载解析等等) ，那么我们就不需要愚蠢的前缀。

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

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

我所有的项目都用匈牙利命名法。当我处理100个不同的标识符名称时，我发现这真的很有帮助。

例如，当我调用一个需要字符串的函数时，我可以键入‘ s’，然后点击 control-space，我的 IDE 会准确地显示以‘ s’开头的变量名。

另一个好处是，当前缀 u 为 unsigned，i 为 signingint 时，我立即看到在哪里以潜在的危险方式混合了有符号和无符号。

我不记得有多少次，在一个庞大的75000行代码基中，由于将本地变量命名为与该类的现有成员变量相同而导致 bug (我和其他人也是如此)。从那以后，我总是在成员前面加上“ m _”

这是一个品味和经验的问题。不要批评它，直到你尝试它。

如今，范围不是比打字更重要吗。

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

随着现代技术的重构旧代码，搜索和替换一个符号，因为你改变了它的类型是繁琐的，编译器会捕捉类型的变化，但往往不会捕捉不正确的使用范围，合理的命名约定在这里有所帮助。

你忘了提供这些信息的首要原因。这跟你没关系，程序员。这和你离开公司2到3年后来到这条路上的人有很大的关系，他们必须阅读这些材料。

是的，IDE 将快速为您标识类型。但是，当您阅读一些长批量的“业务规则”代码时，最好不要在每个变量上停顿一下来查找它是什么类型。当我看到 strUserID、 intProduct 或 guiProductID 之类的东西时，它使得 很多更容易“爬坡”。

我同意 MS 在他们的一些命名惯例上走得太远了——我把它归类为“太多的好东西”。

命名约定是好事情，只要你坚持它们。我已经阅读了足够多的旧代码，这些代码让我不断地回头查看许多名称相似的变量的定义，以至于我推出了“驼峰大小写”(在以前的工作中这样称呼它)。现在我的工作是用 VBScript 编写成千上万行完全没有注释的经典 ASP 代码，想要搞清楚这些是一场噩梦。

Of course when 99% of programmers agree on something, there is something wrong. The reason they agree here is because most of them have never used Hungarian notation correctly.

关于详细的论点，我建议你看看我在博客上发表的一篇关于这个主题的文章。

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

我开始编写代码的时候差不多就是匈牙利命名法被发明出来的时候，第一次被迫在一个项目中使用它的时候，我非常讨厌它。

After a while I realised that when it was done properly it did actually help and these days I love it.

但是就像所有好的事情一样，它必须被学习和理解，而且做好它需要时间。

作为一个 Python 程序员，匈牙利命名法很快就会崩溃。在 Python 中，我不关心 is是否是字符串-我关心的是它是否可以 表现得像是字符串(也就是说，它是否有返回字符串的 ___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_count或 $file_name，可以很方便。

在我看来，匈牙利命名法就像水蛭。也许在过去它们是有用的，或者至少它们看起来是有用的，但是现在它们只是多了很多额外的输入，却没有多少好处。

我倾向于使用 ASP.NET 服务器控件 only的匈牙利命名法，否则我会发现很难搞清楚窗体上的控件是什么。

以下面这段代码为例:

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

如果有人能够展示一种不使用匈牙利语的更好的方法来获得这组控件名称，我会忍不住转而使用它。

I cannot find a link but I remember reading somewhere (which I agree with) that avoiding Hungarian notation results in better programming style.

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

虽然解释起来有点模糊，但我觉得挺管用的。

例如，如果将客户名存储在变量 customerName 中，则不应关心它是字符串还是其他类。更重要的是考虑你想从这个对象得到什么。您希望它打印()、 getFirstName ()、 getLastName ()、 ConvertToString ()等内容吗。一旦您将其作为 String 类的一个实例并认为它是理所当然的，您就限制了您自己和您的设计，因为您必须在代码的其他地方构建所需的所有其他逻辑。

多年来我在程序中使用匈牙利命名法。除了一些视觉上的混乱和当我改变数据类型时改变前缀的任务，没有人能说服我不这样做。直到最近——我不得不将现有的 C # 和 VB.NET 程序集合并到同一个解决方案中。

结果: 我必须向“ sngSome 变量”方法参数传递一个“ fltSome 变量”。即使作为一个同时使用 C # 和 VB. NET 编程的人，它也让我猝不及防，让我停顿了一会儿。(C # 和 VB.NET 有时使用不同的名称来表示相同的数据类型——例如 float 和 single。)

现在考虑这个问题: 如果创建一个可以从多种语言调用的 COM 组件会怎么样？VB.NET 和 C # 的“转换”对于。NET 程序员。但是如果是用 C + + 或 Java 开发的人呢？“ dwSome 变量”对于。NET 开发人员不熟悉 C + + 吗？

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

类型可能也不那么重要。如果你知道这些方法是做什么的，你就可以知道这个变量是做什么的，然后你就可以知道这个程序是做什么的

可能有时候您需要它; 当类型很重要且声明不在附近或者不能轻易推断出类型时。但不应该被视为绝对

乔尔的文章很棒，但似乎忽略了一个主要观点:

匈牙利语使一个特定的“想法”(kind + 标识符名称)独一无二, 或者几乎是唯一的，跨代码库-甚至是一个非常大的代码库。

这对于代码维护来说是个大问题。 这意味着你可以使用好的 ol’单行文本搜索 (grep，findstr，‘ find in all files’)查找每一次提到这个“想法”的地方。

如果我们的 IDE 知道如何读取代码，为什么这一点如此重要呢？ 因为他们还不是很擅长这个，在一个小的代码库中很难看到, 但是很明显，在一个大的-当“想法”可能被提到在评论中, XML 文件、 Perl 脚本，以及源代码管理之外的地方(文档、 wiki、, 漏洞资料库)。

即使在这里，你也必须要小心一点——例如，在 C/C + + 宏中使用令牌粘贴 可以隐藏标识符的提及。这种情况可以使用 coding conventions, and anyway they tend to affect only a minority of the identifiers in the 代码库。

另外，关于使用类型系统和匈牙利语的区别——最好两者都使用。 如果编译器不能为您捕捉到错误的代码，那么您只需要使用错误的代码就可以看到错误的代码。在很多情况下，让编译器捕获它是不可行的。但是在可行的地方——是的，请那样做！

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

应用程序匈牙利对我来说就是希腊语——这是一种好的方式

作为一个工程师，而不是一个程序员，我立即采取乔尔的文章的优点匈牙利应用程序: “让错误的代码看起来错误”。我喜欢匈牙利应用程序，因为它的 模仿工程、科学和数学如何使用子脚本符号和超脚本符号表示方程和公式(像希腊字母，数学运算符等)。以 牛顿万有引力定律为例: 首先是标准数学符号，然后是应用程序中的匈牙利伪代码:

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

在数学符号中，最显著的符号是那些表示存储在变量中的信息的 善良的符号: 力、质量、位置矢量等。下标扮演次要角色来澄清: 位置是什么？这正是匈牙利应用程序正在做的，它首先告诉你存储在变量中的事物的 善良，然后进入细节——关于最接近数学符号的代码。

显然，强类型可以解决 Joel 文章中的安全与不安全字符串示例，但是你不会为位置和速度向量定义单独的类型; 它们都是大小为3的双数组，你可能对其中一个做的任何事情都可能适用于另一个。此外，将位置和速度连接起来(形成一个状态向量)或者取它们的点积，也是非常有意义的，但是可能不需要加上它们。输入如何允许前两种操作，禁止后两种操作，这样的系统如何扩展到您可能想要保护的每一种可能的操作？除非你愿意把所有的数学和物理加密到你的打字系统里。

On top of all that, lots of engineering is done in weakly typed high-level languages like Matlab, or old ones like Fortran 77 or Ada.

因此，如果你有一个奇特的语言，而 IDE 和应用程序匈牙利语并不能帮助你，那么忘记它吧——很多人显然已经忘记了。但是对于我来说，我比一个使用弱类型或动态类型语言的新手程序员更糟糕，我可以使用匈牙利应用程序比没有匈牙利应用程序更快地编写更好的代码。

揭穿匈牙利命名法的好处

• It provides a way of distinguishing variables.

如果类型是区分一个值与另一个值的唯一方法，那么它只能用于将一种类型转换为另一种类型。如果在类型之间转换的值相同，则应该在专门用于转换的函数中执行此操作。(我见过匈牙利的 VB6剩余部分在他们所有的方法参数上使用字符串，仅仅是因为他们不知道如何反序列化一个 JSON 对象，或者正确理解如何声明或使用可空类型。)如果你有两个变量只有匈牙利前缀区别，他们不是从一个到另一个的转换，那么你需要详细说明你的意图与他们。

• 这样代码更易读。

我发现匈牙利命名法使人们懒于使用他们的变量名。他们有一些东西来区分它，他们觉得没有必要详细说明它的目的。这就是你通常会在匈牙利符号代码与现代代码中找到的: sSQL 与 groupSelectSql (或者通常根本没有 sSQL，因为它们应该使用早期开发人员放入的 ORM。) ，sValue 与 formCollectionValue (或者通常也没有 sValue，因为它们碰巧在 MVC 中，应该使用它的模型绑定特性) ，sType 与 PublishSource，等等。

不可能是可读性。我看到更多的 sTemp1，sTemp2... sTempN 从任何给定的匈牙利 VB6剩余比其他所有人加起来。

• It prevents errors.

这是因为数字2是错误的。