我现在工作的公司为其C＃变量使用一组命名约定，例如iSomeName用于int，sSomeName用于字符串，aSomeName用于数组，bSomeName用于布尔值，dSomeName用于日期时间等。我以前的雇主没有使用i，s，a，b和d前缀，只是将变量命名为一个很好理解的名称。我的印象是，这些前缀在不久前失宠了，从我读到的不是当前的趋势。对我来说这两种方式似乎都很好，只要变量具有足够的描述性来理解它在做什么，但我想知道现在每天接受的做法是命名变量是什么？
答案 0 :(得分：7)
嗯，很多命名取决于您使用的语言.. camelCase或PascalCase或underscore_variables。正确命名/可读/可理解是最重要的事情。
关联此前缀（或匈牙利表示法）：MSDN: General Naming Conventions in C#文章中特别注明了这一点：
[...]
不要使用匈牙利表示法。
匈牙利表示法是一种做法 包括标识符中的前缀 编码一些有关的元数据 参数，例如数据类型 标识符。
[...]
答案 1 :(得分：7)
这些问题的通常建议是在您自己的代码内和雇主内部保持一致;如果您的雇主使用匈牙利表示法，您也应该使用匈牙利表示法。
答案 2 :(得分：5)
您以前的雇主更符合当前的做法。带代码的前缀变量目前不被视为最佳实践。你应该现在只做它，如果它澄清代码，它通常不会。对任何类型的前缀的明显需求应被视为次要Code smell，表明当前例程可能过于复杂。花在改进代码上的时间更好，而不是放入前缀。
有关此做法的历史，请参阅Hungarian Notation。名为 Apps匈牙利表示法的版本意味着前缀有助于指示变量的用途，而不是其类型。每隔一段时间这是合法的，但很少有必要。更常见的做法称为系统匈牙利表示法，其中前缀表示类型。 （幸运的是）这种情况变得不那么常见了。
不要太沮丧，不得不这样做。我们不得不实施许多更糟糕的做法。如果这很糟糕，你很幸运。 某些标准（只要它们不疯狂）优于 no standards 。
答案 3 :(得分：4)
“现代”和“流行”的方式是没有匈牙利表示法（i，s等）。原因是重构不再是一个问题。这意味着本质上是批量更改代码而不是特定时间。当你重构东西时，匈牙利表示法很难做到正确，因为它往往是在各种工具的帮助下完成的，这些工具并不知道每个人的定制匈牙利表示法标准。
想象一下，如果对象上有一个iAge成员变量是一个整数。好吧，如果您想将此项从int更改为long，因为此年龄是以毫秒为单位的，该怎么办？那么，你现在还必须将其重命名为lAge。更改类型很容易，也可以自动化，但“创意标准命名”要难得多。实际上，在这个Age变量之前有一个i或者l，它真的告诉你关于代码在做什么的更多信息吗？当然，它告诉你数据类型，但在任何现代IDE中将鼠标悬停在它上面，它也会告诉你数据类型。
简而言之，“现代偏好”确保您的代码的意图易于准备。像匈牙利表示法中的数据类型这样的微不足道的东西只会让人感到困惑。代码很难阅读 - 不要让它变得更糟！
答案 4 :(得分：2)
C＃的现代公认惯例是不使用匈牙利表示法。相反，最佳做法是使用可理解的描述性变量名称。
StyleCop通常用于在C＃中强制执行代码格式化标准，默认情况下不允许使用匈牙利语表示法，尽管它允许通过配置进行例外处理。
答案 5 :(得分：1)
您当前的雇主正在使用Systems Hungarian Notation
我个人看不到此命名约定的价值，因为大多数开发环境都会提供彩色语法突出显示和变量检查，因此您可以轻松确定类型。在最坏的情况下，它会让人感到困惑，因为您可能会更改变量的类型但不会更改变量“prefix”：
double iCount = 0.0;
答案 6 :(得分：1)
您需要参考Framework Design Guidelines，特别是第3章。相同的信息（没有“背景故事”的注释）可用online。
您当前雇主使用的命名系统称为匈牙利表示法，不再由Microsoft推荐。 （事实上，大多数地方不再使用它了。）
答案 7 :(得分：1)
是的，匈牙利语不再使用了，我认为最好使用不言自明的有意义的名字。
如果你想阅读一篇很好的文章（也许转发给大假发：P）关于它，请查看Joel's take on Making Code Ugly and the Hungarian Notation，这是对匈牙利符号为何做出的一个很好的解释，以及它是如何形成的几代人都被滥用了。