“系统匈牙利语”表示法仍然有用吗？[关闭]

我在论坛上进行了搜索，但是找不到为什么应避免使用它的答案，而只是为什么它不是灵丹妙药。所以我不认为这个问题是重复的。

是否有有效的理由为什么我应该取消学习惯用的系统匈牙利语？

到目前为止，我发现使用它具有以下好处：

• 一致的变量命名
• 您无需搜索即可看到类型（智能在半数时间中已失效/已建立索引，因此这仍然是一个合理的原因）
• 语义仍然可以包含在名称的第二部分中

以及以下缺点：

• 惹恼了一些人（不知道为什么）
• 如果更改了类型，则该类型可能与变量的名称不匹配（我不认为这是正当的理由，类型很少更改，并且您拥有“全部重命名”）

所以为什么：

vector<string> vecCityNames;
wstring strCity = L"abc";
//more code here
vecCityNames.push_back(strCity);

差于：

vector<string> cityNames;
wstring city = L"abc";
//more code here
cityNames.push_back(city);//Are we pushing back int on a queue? Float on a stack? Something else?

我曾经使用它（很多年前），现在不再使用。主要原因是它在OO语言中具有强类型（C ++，Java）是多余的，而我恰好使用了我的大部分职业。在这些语言中，如果我很好地定义了类型，则编译器可以并且将为我强制执行类型安全性。因此，任何命名前缀都只会使名称变长，从而使名称难以阅读和搜索。

在任何写得好的OO程序中，大多数变量是用户定义的类型（对它们的引用）。如果为它们加上相同的常规标记（例如o“ object”），则不会从中获得任何好处，而只会带来弊端。但是，如果给它们加上特定于类型的标签作为前缀，就会陷入迷宫，试图为通常具有相似名称*的一千种不同类型查找不同的缩写，并记住在类型或其名称更改时将它们全部更改（即在维护良好的程序中一点都不罕见）。

当然，这不适用于非OO语言，也可能不适用于弱类型和/或动态类型的语言（除C外，我没有使用这些语言的经验）。没有可用的IntelliSense（或其本地等效版本）的编辑器/ IDE都不佳。这只是我的2美分。因此，如果匈牙利符号适合您的团队和项目，那就去做吧。重要的是在项目开始之前就此达成共识（以及通常的一致编码风格），并始终保持一致。

* _{从我们目前的项目只是一个简短的清单：我们有Charge，ChargeBreakdown，ChargeCalculator，ChargeDAO，ChargeDTO，ChargeLineHelper，ChargeMaps，ChargePair和ChargeType，等等。此外，我们在项目中也有Contracts，Countries，Checkouts，Checkins ...，而这只是字母C，OP甚至可能不会将其称为“合理大小”。}

免责声明：我实际上是匈牙利人，所以我相信我可以在这个问题上拥有权威;-)

为什么std::vector<string> vecCityNames;不好？

匈牙利表示法通常使用的问题是，如果分析表明应该将城市名称保留在中std::deque，则所有引用该类型对象的变量名称都将突然具有误导性的名称。

然后要重命名所有变量吗？您是否曾尝试在大型项目中做到这一点？在Murphy的帮助下（那里的人提供了非常多的帮助），某个地方的人肯定会使用诸如这样的变量deqCityNames，使您的更改破坏了构建，使您坐了数小时来摆弄代码，在过去的五年中，没有人敢于看因为害怕被有毒的野兽咬伤。

但是，据我所知，查尔斯·西蒙尼（Charles Simonyi）提出匈牙利语的方式是，该前缀表示变量的语义用法，而不是其句法类型。也就是说，无论采用哪种类型，城市名称列表的正确前缀都可能是listCityNames（或者lstCityNames，如果list对您来说不够神秘）。

但是我认为该前缀是多余的，因为复数（“名称”）已经表明它是一堆城市。底线：当您仔细选择标识符时，几乎不需要匈牙利符号。从长远来看，OTOH的常用用法实际上是在破坏代码。

无论出于何种原因，这里的现有答案似乎都围绕着匈牙利表示法的基本原理，而没有直接说明。在语言本身很难做到的情况下，匈牙利表示法可用于添加类型信息（从类型理论上来说）。碰巧的是，使用C ++或Java的类型系统通常并没有那么困难，以至于匈牙利符号（如通常所描述的）是完全多余的，这可能导致对此产生强烈反对-它增加了程序员的工作可以在我们所有的变量变量中保留这些注释，但是却几乎没有附加值（甚至可能会造成伤害，因为代码看起来更加混乱）。

另一方面，如果有人限制使用匈牙利符号来键入信息（同样，从理论上讲），则不是自然地被语言封装，那么它会非常有用。例如，C和C ++将数组引用作为指针类型传递，但是数组引用和指针具有针对它们执行的不同操作：可以在第一个元素之外对数组建立索引，而指针则不能。这是有用的信息，一旦将数组作为参数传递给函数，该信息就会丢失到类型系统中。因此，在我们的小组中，我们在C和C ++代码中采用了变量名注释，以区分指针变量实际上是指向单个元素的指针还是指向数组的指针。采用此约定在很大程度上减少了我们代码库中内存损坏问题的发生。

惹恼了一些人（不知道为什么）

之所以让我感到烦恼，是因为每个标识符的速度都有些慢，这减慢了我对代码的视觉扫描速度。如果您对q读iEnglish cText像这样，则可能是mAs。

仇恨这个词太强了，IMO。您可以根据需要编写代码。我只是不想在自己的代码中使用匈牙利表示法，并且给出选择后，我也不想在其他人的代码中阅读或使用它。

您问为什么有些人觉得匈牙利的符号很烦人。我不能为别人说话，但是惹恼我的原因是：

1. 它很丑。匈牙利人使用完全合理的名称，并在代码前加上了前缀。将代码内部化之后，我相信这是完全合理的，但是对于未开始使用的人来说，就像是有人在我的源代码上释放了C ++名称错误。

2. 这是多余的。变量的声明确定其类型；我觉得不需要在变量名中重复该信息。并非在每种语言中都是如此：例如，在Perl中，变量名之前的@或$之类的信号基本上定义了变量的类型，因此您别无选择，只能使用它们。

3. 它解决了我没有的问题。方法和函数的时间不要太长，以至于您不得不费劲地查找局部变量或参数的声明，并且它们不应该涉及太多的变量，以至于您难以跟踪什么是什么。在这方面，声明局部变量靠近使用它们的代码也有帮助。过去的C编译器要求在函数的开头声明所有局部变量，但是该限制早已被删除。

4. 还不完整 匈牙利表示法是针对没有类型系统的语言（BCPL）发明的，后来在具有相当有限的本机类型的语言（C）中广泛使用。IMO，它不适用于具有大量类型系统的C ++或Java之类的语言。为什么我要使用前缀来表示本机类型的变量的类型，例如char []，而不是类的变量呢？或者，如果我开始发明vec类的前缀，那么最终我将得到一大堆与我的类层次结构平行的前缀层次。如果这对您有吸引力，那么欢迎您；欢迎您。只是想这让我头疼。

5. 这是模棱两可的，至少据我了解。szFoo和之间有什么区别pszFoo？第一个是零终止字符串，第二个是指向零终止字符串的指针。但是据我所知，在C或C ++中，任何字符串变量实际上都是指针，所以它们相同还是不同？我应该使用哪个？实际答案确实无关紧要-关键是我无法使用本该用来帮助我避免此类问题的符号来识别答案。另一方面，变量的声明必须是明确的，因为它是编译器使用的。

这些就是让我烦恼于匈牙利符号的事情。即使是一个团体，我也不认为他们完全解释了为什么匈牙利人被大量抛弃。这是大多数程序员不使用匈牙利语的三个最大原因：

1. 没有令人信服的理由使用它。请参阅上面的项目3和4。如果匈牙利语比不使用匈牙利语提供了很大的优势，那么我可能会忍受烦恼，但是我看不到，而且其他大多数人也没有。也许关于匈牙利语的最好的事情是它是一种被广泛使用的约定，如果您坚持使用标准约定，则可以合理地期望其他具有类似技能的程序员能够理解该表示法。

2. 非微软公司的影响力增加。可以公平地说，大多数采用匈牙利表示法的程序员都是这样做的，因为这是Microsoft编写代码的方式，并且通常更容易使用。像Google和Apple这样的公司现在的影响范围比过去大得多，并且比以往任何时候都更多的程序员采用了那些避开匈牙利语的公司和其他公司的风格。（公平地指出您仍然会看到一些残留，例如Google和Apple都经常使用'k'前缀作为常量名称。）

3. 微软本身已经放弃了匈牙利语。如果检查其编码指南的Microsoft“ 常规命名约定”部分，则会发现它以粗体显示：不要使用匈牙利表示法。

因此，停止使用匈牙利表示法的一个有效原因是：

匈牙利符号的流行程度已降低到该公约不再有用的地步。如今，很少有程序员使用或什至不了解匈牙利语，因此，该约定在传达应有的信息方面效果不佳。如果您发现在自己的个人项目中编写代码的有用方法，那就没有必要停下来了。但是，如果您是在不使用匈牙利语的团队中编写代码的，那么它可能会成为您与团队其他成员之间的隔离墙，而不是成功的沟通策略。

到目前为止，我发现使用它具有以下好处：

• 一致的变量命名

如果我用《辛普森一家》中的角色命名所有变量，那也是一致的，但这有好处吗？

• 您无需搜索即可看到类型（智能在半数时间中已失效/已建立索引，因此这仍然是一个合理的原因）

基于一个特定工具的弱点，这是唯一有效的理由...

• 语义仍然可以包含在名称的第二部分中

那不是好处。您只是声称没有（巨大的）负面影响。

当我将鼠标悬停在变量上时，IDE会告诉我变量的类型是什么。那么，为什么要麻烦复制这些信息呢？从根本上讲，Systems匈牙利表示法是对DRY的违反，它带有所有与之相关的陷阱。当在现代环境中轻松获得这些信息时，就没有理由为此付出代价。

一致性本身并不是一个优势。不使用类型命名它们也是一致的。如果名称中只有某些变量的类型，则只会出现不一致的情况。将语义打包到第二部分中只是“嗯，还不错。”，其他所有人都可以使用全名来表示语义。您没有列出任何真正的优势。

传统形式的匈牙利符号的另一点是，它们通常是前缀。恕我直言，这里有两个问题：

1）人类读者通常会首先喜欢最重要的信息，在大多数形式的匈牙利语中，可以说编码的信息的重要性不如名称本身。

2）前缀影响词法排序，因此，例如，如果您要使用前缀来表示接口或类，并且您的IDE提供了这些的排序列表，则相关的类/接口将在此列表中分开。

显然，这取决于意见，因此在这里很难处理事实。就个人而言，我觉得该参数为匈牙利命名法运行在强类型，面向对象的语言有点薄。以我的经验，OO应用程序倾向于通过保持类的连贯性和简洁性来处理复杂性，关于功能也可以这样说。这意味着在所有其他条件相同的情况下，您最终得到：

• 更多类别/类型
• 较短的方法

现在，如果要使用匈牙利表示法，则必须决定是全面使用它，还是仅将其用于某些特权类型和类（例如核心库类）。后者对我而言毫无意义，而前者导致了PéterTörök所指的“试图找到千种不同缩写的迷宫”。这意味着在维护缩写列表时会产生很大的开销，并且通常“一致变量命名”已不再可用。

关于较短方法的第二点意味着，在大多数情况下，您将不必通过数百行代码来检查变量的类型。稍微更仔细地命名变量将消除您的其他一些问题-例如cityNamevs. just city。我希望这cityName不是一个浮动:)

关于它为什么使人烦恼-再次，这很可能归因于它是否习惯了。但是作为一个不习惯它的人，我可以告诉您，匈牙利符号的使用打乱了我的眼睛，使代码难以快速阅读。总而言之，我并不是说它没有优点（尽管我没有在重构方面讨论过它的某些缺点），我说的是，对于强类型的OO语言，这样做是不值得的。

我在C ++的上下文中并不知道，但是在Java / C＃领域中，我更喜欢使用有意义的名称来传达域语言或上下文，而不是告诉我它strFirstName是字符串。很明显，这是一个字符串，或者需要重构名称以传达更好的意图。如果您需要一个前缀来知道您正在使用的类型，那么我会认为您的命名不一致，描述性不够或完全错误。在现代语言中，我总是更喜欢名称较长的名称，而不要使名称含糊不清或模棱两可。

我唯一使用匈牙利语的时候是用于ASP.NET控件，而且更重要的是IA）不必键入很长的内容，例如CustomerFirstNameTextBoxvs txtCustomerFirstName和B），因此Intellisense可以对所有控件类型进行排序。即使这样做，我仍然感到“肮脏”，但我还没有找到更好的方法。

嗯-实际上，这完全取决于个人喜好，无论人们如何努力使自己的选择合理化。我个人遵循“何时在罗马……”规则，并在经常调用Windows API的代码中使用匈牙利语。对于独立于平台的代码，我倾向于遵循C ++标准库样式。

答案就在于这个问题：请告诉我如何命名以下变量：

char * nullTerminatedString;
wchar * nullTerminatedWideString;
字符串stlString;
wstring stlWideString;
CString mfcString;
BSTR comString;
_bstr_t atlString;

在这些常量字符串中，添加指向这些常量的指针和指向这些常量的指针。

我非常不喜欢您描述的匈牙利符号形式。原因？90％的时间没有用。

例如，我不得不忍受的一个遗留项目中的一些（相当于C ++。实际上是用Delphi编写的）代码：

pRecords[0]->FooMember=10;

... pRecord是一个变量，其类型为TRecordList。 TRecordList *pRecords[10];

这是一个由名为FooMember的对象组成的类，该对象指向fFooMember ...或mFooMember，具体取决于它是“字段”还是“成员”（提示：它们是同一件事）

问题？fFooMember可能类似于FooMember_，因为我们将始终通过FooMember公共属性对其进行访问。pRecords？很明显，这是您在各处取消引用的事实的指针。TRecordList？什么时候可以混淆类型名称和该类型的对象？编译器会大吼大叫，类型几乎不在对象使用的地方使用（静态属性/方法除外）

现在，有一个地方我确实使用匈牙利符号。这是在处理许多与其他UI变量或常规变量同名的UI变量时。

例如，如果我上面有您名字的表格。

我有一个名为FirstNameForm的类。其中的lblFirstName和txtFirstName分别用于标签和文本框。还有一个公共的FirstName属性，用于获取和设置文本框中的名称。

这也可以通过使用FirstNameLabel和FirstNameTextBox解决，但我发现键入它的时间太长了。特别是像GenderDropDownList之类的东西。

因此，基本上，匈牙利符号充其量是在系统层次上令人讨厌，最坏的情况是有害的（因为其他答案都涉及重构和一致性问题）。