类，方法和变量的命名约定的解释

Question

我目前在大学，他们非常关注遵循他们的标准。

他们曾经告诉我：

所有的类必须以大写字母开头 信

正确

public class MyClass {} 

错误

种

public class myClass {} 
public class _myClass {} 

所有方法都必须以 小写字母

正确

public void doSomething() {} 

不正确的开始

个

public void DoSomething() {} 
public void _doSomething() {} 

所有变量都必须用一个 小写字母

正确

string myString; 

不正确的开始

string MyString; 
string _myString; 

然而在我编程的最后一年，我发现人们使用的规则很不一样。如果仅仅是少数几个使用不同规则的人，并不重要，但几乎在任何地方我都会看到使用这些不同的做法。

所以，我只是想知道背后的上述标准的理由是，其中一些其他的标准被用来原因如下：（他们是错的/旧标准？）

1. 大多数方法我我已经看到以大写字母开头，而不是小写字母 - 几乎我从他们的导入命名空间中使用的任何微软方法。 这可能是最常见的一种，我看到了，我不明白

2. 很多人使用_类变量。

3. 我见过变量的首都 ie。 string MyString;

我知道我错过了一些为好，如果你能想到的任何你可以添加并给予解释为将是有益的。我知道每个人都开发自己的编码风格，但其中的许多实践都有其背后的原因，我宁愿坚持最有意义的。

谢谢
马特

Answer 1

有没有有价值的理由选择一种编码风格，而不是另一种。

最重要的事情是要与你在工作的人们一种编码风格一致。为了帮助大家达成一致的编码风格，你的教授告诉你a编码风格。

大多数时候，这只是一个观点。所以，如果你必须跟大学一起编码，只需按照你的教授的编码风格...。

Answer 2

标准是任意的，就像它的道路上驾驶的一面;只是做他们喜欢他们告诉你这样做;-)

Answer 3

标准只有遵循标准，每个公司或机构都有自己的标准。这是编程最糟糕的部分之一。 ：D

具体讲讲领先_。根据我的经验，这主要用于在类中声明为私有的变量。它们通常与一个方法相结合，以检索它们具有相同的名称而没有前导_。

Answer 4

我试图遵循Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries通过克齐斯茨托夫·克瓦林纳和布拉德·艾布拉姆斯

准则在这本书中有四个主要的形式呈现的规则：不要考虑，不要，不要。这些指令有助于将注意力集中在始终使用的实践，应该普遍使用的实践，应该很少使用的实践以及永远不会使用的实践上。每条指南都包括对其适用性的讨论，并且大多数指南都包含一个代码示例以帮助阐述对话。

另外，您可以使用FxCop检查您是否遵守这些规则。

Answer 5

标准有助于提高可读性，从而提高可维护性。 （因为当您可以更快速，更轻松，更准确地读取代码时，您可以在更短的时间内以更少的工作量进行调试，修复或增强代码）。

它们对可靠性或可用性没有影响，导致计算机不关心变量的命名方式或原始代码的格式。

如果你的代码组织良好，可读性强，你已经达到了目标，无论它是否完全符合任何elses“标准”。

当然，关于如何处理某人开发人员评估工具或管理指标列表中“标准”很高的环境，这并不说明什么......

Answer 6

我看到逻辑背后的类和变量的大写;这意味着你可以做这样的事情

Banana banana; // Makes a new Banana called banana 

最近我一直在学习Qt的，他们也跟着你约定的信。我永远不会遵循微软的命名约定！

Answer 7

我见过的标准回应了Framework Design Guidelines中的内容。在你上面提到的例子中，我没有看到你区分可见性（公共/私人）。

例如：

面向公众的方法应该PascalCase：公共无效的MyMethod（）... 参数的方法应该驼峰：公共无效的MyMethod（字串myParameter）...

该领域应该永远是私人的，应该是camelCase。有些人喜欢用下划线前缀（我）来区分它与方法参数。

最好的办法上的标准是让你的团队在约定同意了前面，当项目揭开序幕，你会发现一切都更加一致。

Answer 8

编码样式基于个人偏好，并且在很大程度上基于您正在使用的语言的功能。

我个人的看法是，选择“正确的”比遵守公约更重要。人们对于自己喜欢的风格可能是教条式的，事情往往会深入到宗教战争中。

1. 的类必须以大写字母开始 - 这又手牵手与变量命名，并有助于防止如果你有两个类，并与相同的规则命名变量的话会产生混乱。我的首选是大写字母，因为我习惯了它，它遵循我的首选语言（C＃）的指导原则。

2. 所有方法都必须以小写字母开头 - 同样，尽管我用大写字母（按照C＃指南）开始我的方法。

3. 所有变量都必须以小写字母开头 - 我相信这取决于您的语言的范围特征。通常人们会在前缀变量（通常是下划线或像“g”这样的字符）来指示变量的作用域（“g”可能意味着“全局”）。这可以帮助防止混淆变量在不同范围内具有相同名称。我的C＃驱动偏好：所有变量都以小写字母开头，我使用“this”。在作用域是一个问题时引用一个具有相同名称的全局变量（这通常只发生在类的构造函数中）。

我不能让3.不用提匈牙利符号（这是严重误用和误解）。 Joel has a great article帮助我更好地理解这些。

Answer 9

除了主要的一点是，尽管任何特定的标准基本上是任意的，而是有根据的标准有些同意这一点很重要，我也想补充一点，有些标准是足够的无处不在已经实现的“正确”的状态中做事的方式。

例如，在java中，专业代码中的类名称是总是在CamelCase中。如果你违反标准，我会限定你的代码将被编译，并且你偶尔也会找到一些打破常规的开源项目，但是我相信大多数人会认为这是作者的标志对语言不太熟悉。大多数教授指导方针都是相当标准的（对于java，无论如何）。在这种情况下，除了恼人的教授之外，可能会激怒陌生人;）

有趣的是，有些语言似乎已将此标准化放在心上，并强制大写以具有特定含义（例如Haskell ）。

Answer 10

你引用的规则是那些在Java世界中普遍使用的规则。

你在做大学的Java代码吗？如果不是这样，那么他们以前可能会教Java，然后切换到C＃但保留了命名约定。

Answer 11

大多数人都在讨论命名约定风格，但在接近命名约定时还有其他事情需要考虑，比如你实际命名的例程。不管你如何格式化，例程（方法，函数和过程）名称通常应该以强动词+对象的形式出现。例如：

paginateResponse() 

或

empty_input_buffer() 

如（分别）相对

dealWithResponse() 

或

process_input_buffer() 

两者 “dealWith” 和 “处理” 是动词，但它们不明确，导致其他编程今后使用你的代码的夯锤必须咨询实际的例程定义以确定它的真实含义。

另一方面，如前两个例子所示，“强”动词的描述能力强大得多，并且真正确定了例程的功能。

这使得您的代码更易于阅读，因为它是自我记录的，并且将带到更高水平的凝聚力。

此外，作为个人风格，我尽量避免以任何名义使用“我的”。