类型和作用域前缀是否值得命名约定？

最近开始担任软件开发人员的第一份工作时，有人被告知我不必在代码中遵循任何命名约定。由从事其他较大项目的小组编写的代码遵循命名约定，但是由于我被邀请编写一个新的独立应用程序，因此感觉并不重要。这是我最后的担心，所以我只是采用了现有的惯例并予以遵守。

int nTickCount  
bool bConnected  
object[] m_aItems  
fSum += fWeight * fValue  
class cManager  
enum etSystemStates  
etSystemStates eState   
cManager.cs

但这真的值得吗？我发现很难判断遵循这种命名约定对理解和检测错误的最终效果，但是，从视觉上看，它看起来很丑陋。另外，在项目中拥有名为cSomething的每个类和文件似乎很精明。

与具有明显不同的事物（例如您所采用的算法和体系结构）相比，我并不觉得这有什么大不了的。但是任何影响我编写的每一行代码的约定似乎都应该正确。

如果完全需要使用一种命名惯例，您会发现什么是最优雅，最有效的命名惯例？它表示类型和/或范围吗？

乔尔·斯波斯基（Joel Spolsky）撰写了一篇文章，阐述了匈牙利表示法为何存在及其意图，这可能有助于回答您的问题。

像tbl这样的数据库表前缀，int的整数等前缀通常是没有用的-在这种情况下，从上下文或开发工具中找出什么是微不足道的。像英制用于英制测量，公制用于公制这样更有意义，因为否则您只能看到它们是浮点数。

area = width * height

看起来很好

impArea = metWidth * impHeight

直接向您显示出问题。

我个人只是使​​用描述性变量名。$ number_of_items显然是一个整数。就语言数据类型和语义类型而言，$ input_file_handle，$ is_active和$ encrypted_pa​​ssword具有明显的类型。

您所描述的称为匈牙利表示法。它曾经被认为是最佳实践，但现在却普遍被皱眉了。

Wikipedia文章包含有关其优缺点的部分。

是的，前缀可能有用，但是我有两个建议：

如果您的整个团队都使用相同的约定，那么它们将变得更加有用。独自使用它们的帮助较小。

在强类型的静态类型语言中，不要只复制变量的类型。例如，“ bSubscribed”在C＃或Java中是布尔变量的坏名称，因为您的IDE已经知道它是什么类型。另一方面，在缺少布尔类型的C中，这将是有用的信息。

在C＃和Java中，您可以考虑使用前缀来表明对象可能为null。或该字符串已被html换码。或表示正则表达式或sql语句。或该数组已排序。动用你的想象力。

基本上，这是一个问自己的问题，您想要一个变量名告诉您什么，这很大程度上取决于您使用的域和语言。

命名约定有几种不同的“样式”，其中大多数在使代码易于理解方面具有一定的价值。

FAR更重要的是：对变量和函数使用描述性名称。在带有“ sum”，“ weight”和“ value”的示例中，您可能想要给出更有意义的名称：“ totalCost”，“ lumberWeight”，“ lumberValuePerOunce”（我在这里做一些假设）

我发现像在变量名前加一个字符这样的约定，在大多数现代语言中，该字符表示类型都很分散注意力。

大多数.NET开发人员都遵循Microsoft的设计指南（http://msdn.microsoft.com/zh-cn/library/ms229042.aspx），该指南 与Java非常相似（主要区别是Microsoft赞成使用Pascal Case作为成员名，而Java偏爱骆驼案）。

除此之外，由于添加了额外的噪音，我想说您的代码示例的可读性要差得多。

我发现，在大多数情况下，Google的编码风格指南相当不错。由于您被告知可以使用自己喜欢的任何样式，因此我认为您应该先仔细研究一下，然后从中进行选择。

给变量名加上数据类型（尤其是原始数据类型）前缀会增加视觉噪音，并增加否则小的更改将成为重命名的风险。

关于第一点，“ intStudentCount”真的比“ numberOfStudents”更清晰吗？“ invoiceLineItems”至少不会像“ aobjItems”一样有用。（数据类型应与问题域中数据的含义有关，而不是与底层表示有关。）

关于第二点，例如，如果将过早选择的int替换为long或double会发生什么？更糟的是，当将一个具体的类重构为具有多个实现类的接口时，会发生什么？任何增加现实维护场景负担的实践对我来说都是可疑的。

这可能还取决于您为什么要为该名称加上前缀，而不是仅加上前缀。

例如，我倾向于在表单上的控件名称上使用1-2个字母的前缀。并不是因为我不知道编译器会轻松地为按钮找到合适的类（例如），但是我倾向于先设计大表格，然后再编写大多数代码。

在按钮上使用bt前缀可以轻松地在以后找到正确的按钮，而不是将许多名称混在一起。

但是，我既不使用前缀来命名变量，也没有使用类型（无论如何通常没有用），也不使用含义，上下文或单位（这是匈牙利表示法的原始思想）。

我认为，这取决于项目的语言和规模。实际上，我从未在所有变量上都使用类型前缀，但是您确实想以一种清晰的方式命名它们。

使用静态类型的语言（例如您所使用的语言），我对类型系统越感到自在，匈牙利符号的重要性就越低。因此，在Java或C＃中，尤其是在Haskell中，我什至不考虑添加这些前缀，因为您的工具可以告诉您任何给定表达式的类型，并且会捕获由于误解类型而导致的大多数错误。

前缀通常对对象有意义，例如，在某种形式中，您可能有20个文本框将其全部 tbSomething有意义。

但是，大多数情况下，我认为这不值得，特别是对于值类型。

例如，假设您有：

short shortValue = 0;
//stuff happens

几个月后，您发现需要进行更改-短的不够大。现在您有了：

int shortValue = 0;
//stuff happens

除非您现在也更改变量的名称（在这种情况下，更改代码的风险要大于更改类型的风险），否则您现在会产生混乱的代码。

最好使用一个描述其含义的名称：

int loopCounter = 0;
//stuff happens

如果以后需要更改很长的时间，那就没问题了。

对于动态类型的语言或没有IDE的这些约定，可能还有更多的论据。

我一直很容易在变量本身前面的类型中使用2到4个字符的缩写。有时这似乎很乏味，但是当您处理复杂的数据类型或情况时，它将变得很有用。我认为它属于小骆驼案件类别。

在上面的示例中，它会稍作调整：

int intTickCount;
bool boolConnected;
object[] aobjItems;

数组在类型前面总是有一个a来指定数组。这也使我可以将相似的变量实例组合在一起。例如，我可以使用...

taStore.Fill(dtStore);

...表明我的Store TableAdapter正在填充Store DataTable。

我一直试图遵循基本原则，即只有在使代码更具可读性时才插入前缀和/或后缀（如普通英语）。

秘密越少越好...

为什么会有这样的方法：

public boolean connect( String h, int p );

当您可以拥有这样的东西时：

public boolean connect( String hostName, int port );

而且，今天的IDE确实具有强大的工具来重构（尤其是Java）变量，方法名，类等。...说用最少的字符数获得最大信息只是一种老式的想法。