int，string，array，list，object等可接受的命名约定是什么

Question

我现在工作的公司为它们的C＃变量使用一组命名约定，例如iSomeName用于int，sSomeName用于字符串，aSomeName用于数组，bSomeName用于布尔值，dSomeName用于datetime等等。 我以前的雇主没有使用i，s，a，b和d前缀，只是将变量命名为一个很好理解的名称。 我的印象是，这些前缀在不久前失宠了，从我读到的不是当前的趋势。 对我来说似乎很好，只要变量具有足够的描述性来理解它正在做什么，但我想知道现在一天接受的做法是命名变量？

Answer 1

好吧，很多命名取决于你使用的语言.. camelCase或PascalCase或underscore_variables 。 正确命名/可读/可理解是最重要的事情。

关于这个前缀 （或匈牙利表示法）：它在MSDN中具体说明：C＃文章中的一般命名约定 ：

[...]

不要使用匈牙利表示法。

匈牙利表示法是在标识符中包括前缀以编码关于参数的一些元数据的实践，例如标识符的数据类型。

[...]

Answer 2

对这些问题的通常建议是在您自己的代码内和雇主内部保持一致; 如果您的雇主使用匈牙利表示法，您也应该使用它，无论接受的做法如何。

Answer 3

您以前的雇主更符合当前的做法。 使用代码对变量进行前缀不是最佳实践 。 你应该现在只做它，如果它澄清代码，它通常不会。 对任何类型的前缀的明显需求应被视为次要的Code气味 ，表明当前的例程可能过于复杂。 花时间改善代码而不是添加前缀。

有关此练习的历史，请参阅匈牙利表示法 。 名为Apps Hungarian表示法的版本意味着前缀有助于指示变量的用途，而不是其类型。 每隔一段时间这是合法的，但很少有必要。 更常见的做法称为系统匈牙利表示法 ，其中前缀表示类型。 （幸运的是）这种情况变得不那么常见了。

不要太沮丧，不得不这样做。 我们不得不实施许多更糟糕的做法。 如果这很糟糕，你很幸运。 有一些标准 （只要他们不疯狂）比没有标准更好。

Answer 4

“现代”和“流行”的方式是没有匈牙利表示法（i，s等）。 原因是重构不再是一个问题。 这意味着本质上是批量更改代码而不是特定时间。 当你重构东西时，匈牙利表示法很难做到正确，因为它往往是在各种工具的帮助下完成的，而这些工具并不知道每个人的自定义匈牙利表示法标准。

想象一下，如果你在一个整数的对象上有一个iAge成员变量。 那么，如果你想将这个从int更改为long因为这个年龄是以毫秒为单位的呢？ 那么，你现在还必须将它重命名为lAge 。 更改类型很容易，也可以自动化，但“创意标准命名”要难得多。 实际上，在这个Age变量之前有一个i或者l，它真的告诉你关于代码在做什么的更多信息吗？ 当然，它告诉您数据类型，但在任​​何现代IDE中将鼠标悬停在它上面，它也会告诉您数据类型。

简而言之，“现代偏好”确保您的代码的意图易于准备。 像匈牙利表示法中的数据类型这样的微不足道的东西只会让人感到困惑。 代码很难阅读 - 不要让它变得更糟！

Answer 5

C＃现代公认的做法是不使用匈牙利表示法。 相反，最佳做法是使用可理解的描述性变量名称。

StyleCop通常用于在C＃中强制执行代码格式化标准，并且默认情况下不允许匈牙利语表示，尽管它允许通过配置进行异常。

Answer 6

您当前的雇主使用的是匈牙利语系统表示法

我个人认为这个命名约定没有价值，因为大多数开发环境都会提供彩色语法高亮和变量检查，因此您可以轻松确定类型。 在最坏的情况下，它会让人感到困惑，因为您可能会更改变量的类型但不会更改变量“prefix”：

double iCount = 0.0;

Answer 7

你需要参考框架设计指南 ，特别是第3章相同的信息（不带注释的“背后的故事”）可在网上 。

您当前雇主使用的命名系统称为匈牙利表示法，不再由Microsoft推荐。 （事实上​​，大多数地方不再使用它了。）

Answer 8

是的，匈牙利语不再使用了，我认为最好使用有意义的有意义的名字。

如果你想阅读一篇很好的文章（也许转发给大假发：P）关于它，请查看Joel对制作代码丑陋和匈牙利符号的看法 ，这是为什么匈牙利符号的制作，以及如何它已经被几代人滥用了。