不使用匈牙利表示法的好处是什么？

我苦苦挣扎的事情之一就是不使用匈牙利符号。我不想仅去查看变量类型是什么，就不必去定义变量。当一个项目扩展时，能够查看以'bool'为前缀的变量并知道它正在寻找true / false而不是0/1值，这是一个很好的选择。

我还在SQL Server中做了很多工作。我在存储过程中添加了“ sp”前缀，在表中添加了“ tbl”前缀，更不用说数据库中的所有变量了。

我到处都看到没有人真正想要使用匈牙利符号，以至于避免使用匈牙利符号。我的问题是，不使用匈牙利符号的好处是什么？为什么大多数开发人员都像瘟疫一样避免使用匈牙利符号？

由于其原始意图（请参阅http://www.joelonsoftware.com/articles/Wrong.html和http://fplanque.net/Blog/devblog/2005/05/11/hungarian_notation_on_steroids）已经被误解了，并且已经被（ ab）用于帮助人们记住他们使用的语言不是静态类型的变量的类型。在任何静态类型的语言中，您不需要添加前缀镇流器即可告诉您变量是什么类型。在许多无类型的脚本语言中，它可以提供帮助，但是经常被滥用，以至于变得完全笨拙。不幸的是，人们没有回到匈牙利符号的初衷，而是将其变成了您应该避免的那些“邪恶”事物之一。

简而言之，匈牙利表示法旨在为变量添加一些语义。例如，如果您具有屏幕坐标（左，上，右，下），则可以在具有绝对屏幕位置的abs变量前加上“ ”，在相对于窗口的位置处的变量前带有“ rel”。这样，当您将相对坐标传递给需要绝对位置的方法时，对于任何读者来说都是显而易见的。

更新（针对delnan的评论）

恕我直言，滥用形式应避免像瘟疫一样，因为：

• 它使命名变得复杂。当（ab）使用匈牙利表示法时，总是会讨论前缀的具体程度。例如：listboxXYZ或MyParticularFlavourListBoxXYZ。
• 它使变量名更长，而无助于理解变量的用途。
• 为了避免长前缀将其缩短为缩写，并且您需要一本字典来了解每个缩写的含义时，这样做会打败练习的目的。是ui无符号整数吗？未引用的计数接口？与用户界面有关？那些事情可能会变得漫长。我已经看到超过15个看似随机的字符的前缀，这些前缀应该传达var的确切类型，但实际上只是个谜。
• 它很快就会过时。当您更改变量的类型时，人们总是（lol）忘记更新前缀以反映更改，或者故意不更新它，因为这会在使用var的任何地方触发代码更改...
• 它使代码讨论变得更加复杂，因为它为“ @g”。说：带有匈牙利符号的变量名通常是很难发音的字母汤。这会妨碍可读性和讨论代码，因为您不能“说出”任何名称。
• ...还有更多我现在不记得的事情。也许是因为我很高兴不必长时间处理滥用的匈牙利符号...

匈牙利表示法是现代编程环境和重言式形式中的一种命名反模式。

它无用地重复了信息，没有任何好处，也没有额外的维护开销。当您将其更改int为其他类型（如）时会发生什么long，现在您必须搜索并替换整个代码库以重命名所有变量，否则它们现在在语义上是错误的，这比没有在名称中重复该类型的情况更糟。

它违反了DRY原理。如果必须在数据库表前面加上缩写词以提醒您它是一个表，那么您在语义上绝对不足以对表进行命名。您执行此操作的其他所有内容也是如此。在现代开发环境中，这只是多余的打字和工作，没有收益或收益。

维基百科列出了匈牙利符号的优缺点，因此可以为这个问题提供最全面的答案。在显着很有高见也是一个相当有趣的阅读。

不使用匈牙利符号的好处基本上只是避免了它的缺点：

• 当编译器进行类型检查时，匈牙利表示法是多余的。提供类型检查的语言编译器可确保变量的使用自动与其类型一致；肉眼检查是多余的，并且容易出错。

• 所有现代的集成开发环境都按需显示变量类型，并自动标记使用不兼容类型的操作，从而大大简化了该表示法。

• 匈牙利表示法用于表示多个属性时，会引起混淆，例如a_crszkvc30LastNameCol：常量引用参数，其中LastName包含类型数据库的列的内容，该列varchar(30)是表主键的一部分。

• 修改或移植代码时，可能导致不一致。如果更改了变量的类型，则变量名称上的修饰符将与新类型不一致，或者必须更改变量的名称。一个特别著名的示例是标准WPARAM类型，以及wParam许多Windows系统函数声明中随附的形式参数。“ w”代表“单词”，其中“单词”是平台硬件体系结构的本机单词大小。它最初是16位字体系结构上的16位类型，但后来在更高版本的操作系统中更改为32位字体系结构上的32位，或在64位字体系结构上更改为64位类型。原始名称（其真正的基础类型是UINT_PTR，即一个足以容纳指针的无符号整数）。语义上的阻抗以及由此引起的程序员从平台到平台的混乱和不一致，是基于“ w”在那些不同的环境中代表16位的假设。

• 大多数时候，知道变量的使用就意味着知道变量的类型。此外，如果不知道变量的用法，则无法从变量的类型中推导出该变量。

• 匈牙利表示法大大降低了使用功能丰富的代码编辑器支持变量名补全的好处，因为程序员必须首先输入整个类型说明符。

• 通过使用不必要的类型和作用域前缀来混淆变量的用途，它使代码的可读性降低。

• 附加的类型信息可能不足以替换更多描述性名称。例如，sDatabase它不会告诉读者它是什么。databaseName可能是更具描述性的名称。

• 当名称具有足够的描述性时，其他类型信息可能是多余的。例如，firstName很可能是字符串。因此，命名sFirstName只会给代码增加混乱。

我自己不使用此表示法，因为我不喜欢不必要的技术噪音。我几乎总是知道我要处理哪种类型，并且我想在域模型中使用一种简洁的语言，但是我主要使用静态和强类型的语言编写。

作为MS SQL Server的特定问题：

首先在Master数据库中搜索所有带有“ sp_”前缀的存储过程，而不是在其中创建该存储过程。这将导致存储过程的执行被延迟。

IMO不使用匈牙利语的最大好处是，它迫使您使用有意义的名称。如果正确命名变量，则应该立即知道它是什么类型，或者能够在任何设计良好的系统中快速推断出它。如果您需要依靠str或者bln甚至更糟的是obj前缀知道一个变量是什么类型的，我认为它表明一个命名问题-一般要么差变量名或方法过于笼统传达意义。

具有讽刺意味的是，从个人经验来看，我看到匈牙利人使用的主要场景是“载有货物的”编程（即其他代码正在使用它，所以让我们继续使用它仅仅是因为）或在VB.NET中解决该语言是不区分大小写的（例如，Person oPerson = new Person因为您不能使用Person person = new Person并且Person p = new Person太模糊）；在这种情况下，我还看到在“ the”或“ my”之前加上前缀（如in Person thePerson = new Person或uglier Person myPerson = new Person）。

我将添加我唯一的匈牙利语倾向用于ASP.NET控件的时间，这确实是一个选择问题。我发现键入TextBoxCustomerName或CustomerNameTextBox比较简单的字体非常难看txtCustomerName，但即使那样也感觉“肮脏”。我觉得有些类型的命名约定应该用于控件还可以有一个显示相同数据的多个控件。

自从您提到它以来，我将仅关注SQL Server。我认为没有理由将“ tbl”放在桌子前。您可以查看任何tSQL代码，并根据使用方式区分表。您永远不会Select from stored_procedure.或不会Select from table(with_param)喜欢UDF或Execute tblTableOrViewName喜欢存储过程。

表可能会与View混淆，但是涉及到如何使用它们；没有区别，那有什么意义呢？匈牙利符号可以为您节省在SSMS（在表还是视图下）中查找它的时间，仅此而已。

变量可能会带来问题，但是需要声明它们，实际上，您打算将变量声明到自己的声明语句之外吗？除非您要编写很长的过程，否则滚动几行就没什么大不了的。分解冗长的代码可能是个好主意。

您描述的是一种痛苦，但是匈牙利表示法解决方案并不能真正解决问题。您可以查看其他人的代码，发现变量类型可能会更改，现在需要更改变量名称。只是要忘记的一件事。而且，如果我使用VarChar，则无论如何都要看一下声明语句来知道大小。描述性名称可能会让您更进一步。@PayPeriodStartDate几乎可以自我解释。

要补充的另一件事是，对于.NET这样的整个框架，您将使用什么缩写？是的，记住btn一个按钮和txt一个文本框非常简单。但是，您对诸如此类的东西有什么想法StringBuilder？strbld？那CompositeWebControl呢 您是否使用类似以下的内容：

CompositeWebControl comWCMyControl = new CompositeWebControl();

匈牙利表示法的低效率之一是，通过拥有越来越大的框架，事实证明，这不仅增加了额外的利益，而且还为开发人员增加了更多的复杂性，因为他们现在必须越来越多地学习非标准前缀。

就我看事物的方式而言，匈牙利表示法是绕过功能不够强大的类型系统的k俩。在允许您定义自己的类型的语言中，创建一个新类型来对您期望的行为进行编码的过程比较简单。在Joel Spolsky关于匈牙利表示法的专栏文章中，他举例说明了变量或函数不安全（我们）或安全（一个或多个）的使用，但使用它来检测可能的XSS攻击，但这仍然需要程序员进行直观检查。如果您有一个可扩展的类型系统，则可以只创建两个新类型UnsafeString和SafeString，然后在适当时使用它们。另外，编码的类型变为：

SafeString encode(UnsafeString)

并且无法访问UnsafeString的内部结构或使用某些其他转换函数成为从UnsafeString转换为SafeString的唯一方法。如果所有输出函数仅使用SafeString实例，则无法输出未转义的字符串[禁止使用带有诸如StringToSafeString（someUnsafeString.ToString（））之类的转换的恶作剧]。

很明显，为什么允许类型系统对代码进行完整性检查优于尝试手动进行检查，或者在这种情况下可能会引起注意。

当然，在诸如C之类的语言中，您会因为int是int是int而陷入困境，对此您无能为力。您总是可以玩带有结构的游戏，但是这是否有进步是值得商bat的。

至于匈牙利表示法的其他解释，IE以变量类型作为前缀，这只是愚蠢的做法，它鼓励像命名变量uivxwFoo之类的懒惰做法，而不是像countOfPeople这样有意义的事情。

在静态类型的语言中，匈牙利表示法几乎完全没有用。这是一项基本的IDE功能，可以通过将鼠标放在变量上或通过其他方式显示变量的类型。此外，如果没有类型推断，您可以通过在声明位置几行来了解类型。类型推论的重点是不要到处重复类型的干扰，因此在使用类型推论的语言中，匈牙利符号通常被认为是一件坏事。

在动态类型的语言中，它有时会有所帮助，但对我而言，这感觉很独特。您已经放弃了只限于确切的域/共域的功能；如果所有变量都用匈牙利符号命名，那么您只是在重现类型系统将给您的内容。如何用匈牙利表示法表示多态变量，可以是整数或字符串？“ IntStringX”？“ IntOrStringX”？我曾经用过匈牙利符号的唯一地方是汇编代码，因为我试图找回如果我拥有类型系统会得到的东西，这是我编写过的第一件事。

无论如何，我不太在乎人们如何命名变量，代码可能仍然是难以理解的。开发人员在样式和变量名等方面浪费了太多时间，最终，您仍然会获得大量使用不同语言约定的库。我正在开发一种符号（即非基于文本的）语言，其中没有变量名称，只有唯一的标识符，以及变量的建议名称（但是大多数变量仍然没有建议名称，因为根本不存在用于变量的合理名称）他们）; 审核不受信任的代码时，您不能依赖变量名。

在这种情况下，像往常一样，我会在阅读其他参与者的答案之前发布答案。 

我在您的视野中看到了三个“错误”： 

1）如果您想了解变量/参数/属性/列的类型，可以将鼠标悬停或单击它，在大多数现代IDE中，它都会显示出来。我不知道您在使用什么工具，但是上次我被迫在没有提供此功能的环境中工作是在20世纪，语言是COBOL，哎呀，它不是Fortran，而我的老板不明白我为什么离开。 

2 /在开发周期中类型可能会更改。32位整数在某些时候可能会变成64位整数，这是由于项目开始时未检测到的充分原因。因此，将intX重命名为longX或使用指向错误类型的名称来保留它是不好的业力。 

3）您要求的实际上是多余的。冗余不是很好的设计模式或习惯。甚至人类都不愿过多地冗余。甚至人类都不愿过多地冗余。 

我认为迫切需要匈牙利是一种症状。全局变量过多
的征兆...或者函数的时间太长而无法维护。

如果您看不到变量定义，通常会遇到麻烦。
而且，如果您的函数没有遵循一些令人难忘的约定，那么麻烦就大了。

我想这就是...很多工作场所将其破灭的原因。

它起源于语言是需要它。
关于全局变量bonanza的时代。（因为没有其他选择）
它对我们很有帮助。

唯一真正使用我们今天它是乔尔Spolsky的一个。
跟踪变量的某些特定属性，例如其安全性。

（如 “变量是否safeFoobar有一个绿色的光被注入到一个SQL查询？
-就像它的名字safe，是”）

其他一些答案则涉及编辑器功能，这些功能有助于您在变量上悬停时查看变量的类型。在我看来，这些对于代码的健全性也是有问题的。我相信它们只是用于重构，还有许多其他功能（例如功能折叠），不应在新代码上使用。

我认为不使用匈牙利符号的原因已被其他海报很好地涵盖了。我同意他们的意见。

对于数据库，我对在代码中很少使用的DDL对象使用匈牙利符号，但否则会在命名空间中发生冲突。主要是归结为前缀索引和命名约束及其类型（PK，UK，FK和IN）。使用一致的方法来命名这些对象，并且您应该能够通过查询元数据来运行一些验证。

避免它的原因是由于系统匈牙利人违反了DRY（前缀恰好是编译器和（好的）IDE可以派生的类型）

应用使用变量的匈牙利OTOH前缀（即scrxMouse是屏幕上的ax坐标，它可以是int，short，long甚至是自定义类型（typedef甚至可以让您轻松更改它））

对制度的误解是摧毁匈牙利人的最佳做法

假设我们有一个这样的方法（在C＃中）：

int GetCustomerCount()
{
    // some code
}

现在在代码中我们这样称呼它：

var intStuff = GetCustomerCount();
// lots of code that culminates in adding a customer
intStuff++;

该INT并没有告诉我们很多。仅仅是int的事实并不能告诉我们其中包含什么。现在，让我们假设我们这样称呼它：

var customerCount = GetCustomerCount();
// lots of code that culminates in adding a customer
customerCount++;

现在我们可以看到变量的用途。如果我们知道它是整数，那会不会很重要？

但是，匈牙利语的最初目的是让您执行以下操作：

var cCustomers = GetCustomerCount();
// lots of code that culminates in adding a customer
cCustomers++;

只要您知道c代表什么，就可以了。但是您必须有一个标准的前缀表，每个人都必须了解它们，任何新手都必须学习它们才能理解您的代码。而customerCount或者countOfCustomers是乍一看很明显的。

匈牙利语在Option Strict On存在之前在VB中具有某些用途，因为在VB6和更早的版本（以及在VB .NET中Option Strict Off）中，VB会强制类型，因此您可以这样做：

Dim someText As String = "5"
customerCount = customerCount + someText

这很不好，但是编译器不会告诉您。因此，如果您使用匈牙利语，至少您将对正在发生的事情有所了解：

Dim strSomeText As String = "5"
intCustomerCount = intCustomerCount + strSomeText  // that doesn't look right!

在.NET中，使用静态类型输入是不必要的。匈牙利人经常被用来代替良好的命名。忘记匈牙利语，取而代之的是好名声。

我发现有很多反对的理由，但是我没有看到：人体工程学。

以前，当您只需要字符串，int，bool和float时，字符sibf就足够了。但是使用字符串+短时，问题就开始了。使用全名作为前缀，还是使用str_name作为字符串？（虽然名称几乎总是字符串-不是吗？）Street类是什么？名称变得越来越长，即使您使用CamelCase，也很难说出类型前缀在哪里结束以及变量名在哪里开始。

 BorderLayout boderLayoutInnerPanel = new BorderLayout ();
 panelInner.addLayout (borderLayoutInnerPanel);

好的-如果您还没有使用下划线，则可以使用下划线；如果使用下划线的时间过长，则可以使用CamelCase：

 BorderLayout boderLayout_innerPanel = new BorderLayout ();
 panel_inner.addLayout (borderLayout_innerPanel);

 Border_layout boder_layoutInner_panel = new Border_layout ();
 panelInner.add_layout (border_layoutInner_panel);

这太可怕了，如果您这样做，您将有

 for (int iI = 0; iI < iMax-1; ++iI)
     for (int iJ = iI; iJ < iMax; ++iMax) 
          int iCount += foo (iI, iJ); 

对于琐碎的情况，您最终都会使用无用的前缀，例如循环变量或count。您最近是什么时候使用空头或多头来进行交易的？如果您设置例外，则通常会浪费时间，考虑是否需要前缀。

如果您有很多变量，通常在IDE的对象浏览器中将它们分组。现在，如果40％的整数以i_开头，而s_的字符串以40％开头，并且它们按字母顺序排序，则很难找到名称的重要部分。

我仍然经常使用匈牙利语或类似的后缀的地方是在同一语义数据以两种不同形式（例如数据转换）存在的情况下。这可能是在存在多个度量单位或存在多种形式（例如字符串“ 123”和整数123）的情况下。

我发现这里给出的不使用它的理由令人信服，因为它没有将匈牙利语强加给其他人，而只是出于暗示，决定了自己的做法。

程序的源代码本身就是一个用户界面，向维护者显示算法和元数据，而用户界面中的冗余是一种美德，而不是一种罪过。参见例如“ 日常事物的设计 ”中的图片，并查看带有“推”字样的门，就像拉动它们一样，并查看操作人员闯入重要核反应堆控制装置的啤酒水龙头，因为它们“悬停在他们在IDE中”还不够好。

“仅在IDE中徘徊” 并不是不使用匈牙利语的原因-只是某些人可能认为它没有用的原因。您的里程可能会有所不同。

当变量类型更改时，匈牙利人会承受大量维护负担的想法很愚蠢-您多久更改一次变量类型？此外，重命名变量很容易：

只需使用IDE重命名所有事件。 -甘德，回复鹅

如果匈牙利语确实可以帮助您快速读取一段代码并可靠地对其进行维护，请使用它。如果没有，那就不要。如果其他人告诉您您对自己的经历是错误的，我建议他们可能是错误的人。