类，方法和变量的命名约定的说明

Question

我现在在大学，他们非常注重遵循他们的标准。

他们告诉了我：

  

所有课程必须以资本开头   信

正确

public class MyClass {}

不正确

public class myClass {}
public class _myClass {}

  

所有方法必须以a开头   小写字母

正确

public void doSomething() {}

不正确

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

  

所有变量必须以a开头   小写字母

正确

string myString;

不正确

string MyString;
string _myString;

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

所以我只是想知道上述标准背后的原因是什么以及为什么使用其他一些标准:(它们是错误/旧标准吗？）

1. 我见过的大多数方法都是以大写字母而不是小写字母开头 - 几乎是我从导入的命名空间中使用的任何微软方法。 这可能是我见过的最常见的我不明白

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

3. 我在变量上看到了大写即。 string MyString;

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

谢谢，
马特

Answer 1

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

最重要的是与您正在处理的人达成一致的编码风格。为了帮助您达成编码风格，您的教授告诉您 编码风格。

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

Answer 2

标准是任意的，就像开车的哪一边;就像他们告诉你这样做一样; - ）

Answer 3

大多数人都在谈论命名约定 style ，但在接近命名约定时还需要考虑其他事项，例如你实际命名的例程。

常规（方法，函数和过程）名称通常应采用强动词+对象的形式，无论您如何格式化它。例如：

paginateResponse()

或

empty_input_buffer()

as（分别）反对

dealWithResponse()

或

process_input_buffer()

“dealWith”和“process”都是动词，但是它们含糊不清，导致将来使用你的代码的任何其他程序员必须查阅实际的例程定义来确定它的真正作用。

另一方面，如前两个例子中所示，“强”动词在描述能力方面要强大得多，并且能够确定例程正在做什么。

这使您的代码更容易阅读，因为它是自我记录的，引导更高的凝聚力。

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

Answer 4

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

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

Answer 5

我试图遵循Krzysztof Cwalina和Brad Abrams的Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries规则

  

本书中的指南以四种主要形式呈现：做，考虑，避免和不做。这些指令有助于将注意力集中在应该始终使用的实践，通常应该使用的实践，应该很少使用的实践以及不应该使用的实践中。每个指南都包含对其适用性的讨论，大多数都包含一个代码示例，以帮助阐明对话。

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

Answer 6

标准有助于提高可读性，从而提高可维护性。 （因为当你能够更快，更容易，更准确地阅读代码时，你可以用更少的时间和更少的精力调试和修复它，或者增强它。）

它们对可靠性或可用性没有影响，因为计算机不关心变量的名称或源代码的格式化。

如果您的代码组织良好且易读，那么您已经实现了目标，无论它是否完全符合任何“标准”。

当然，这并没有说明如何处理某些开发人员评估工具或管理指标列表中“标准”较高的环境......

Answer 7

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

这样的事情

Banana banana; // Makes a new Banana called banana

我最近一直在学习Qt，他们遵循你的约定。我不会遵循微软的命名惯例！

Answer 8

我看到的标准与Framework Design Guidelines中的内容相呼应。在上面提到的示例中，我没有看到您区分可见性（公共/私人）。

例如：

面向公众的方法应该是PascalCase：public void MyMethod（）... 方法的参数应该是camelCase：public void MyMethod（string myParameter）...

应始终为私有的字段应为camelCase。有些人更喜欢下划线前缀（我这样做），以区别于方法参数。

标准的最佳选择是让你的团队在项目启动时事先就大会达成一致，你会发现一切都更加一致。

Answer 9

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

我个人认为，与选择一致而不是选择“正确的”更为重要。人们可能会教条他们是首选的风格，而事情往往会深入到宗教战争中。

1. 所有类必须以大写字母开头 - 这与变量命名密切相关，有助于防止在同时使用相同命名的类和变量时出现的混淆规则。我的偏好是大写字母，因为我已经习惯了，它遵循我的首选语言（C＃）的指导原则。

2. 所有方法必须以小写字母开头 - 同样如此，尽管我使用大写字符开始我的方法（根据C＃指南）。

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

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

Answer 10

除了要点之外，虽然任何特定的标准基本上是任意的，但是有一些商定的标准是很重要的，我还要补充一些标准无处不在，以达到“正确”方式的地位做事。

例如，在java中，专业代码中的类名在CamelCase中始终。如果你破坏了标准，我总是会说你的代码会编译，你可能偶尔也会发现一些违反惯例的开源项目，但我相信大多数人会认为这是作者的一个标志。对语言不太熟悉。你的大多数教授指南都是相当标准的（对于java，无论如何）。在这种情况下完全不同，除了烦恼你的教授，可能会激怒陌生人;）

有趣的是，有些语言似乎已经将这种标准化牢记在心，并强制大写具有特定的意义（例如Haskell）。

Answer 11

您引用的规则是Java世界中普遍使用的规则。

你在大学做Java代码吗？如果没有，可能是他们以前教过Java，然后切换到C＃但保留了命名约定。