是否应该对类成员进行排序？

Question

在有新团队的新项目中，我们是否应该强制在签入之前按照特定的顺序(例如，按修饰符和字母表)对类的成员进行自动排序？

另一种选择是让每个开发人员按照自己的想法对成员进行分组。由于每个人对什么是相关的以及如何分组有不同的看法，这在很大程度上归结为随机顺序。

那么让它们自动排序的利弊是什么呢？这是否绑定到特定的IDE/development-process/build-process/language？我们还需要考虑什么？

编辑以培养更多的答案：

我曾经参与过一个项目，其中我们必须维护几个分支。由于RCS无法适当地支持这一点(当时是SVN)，我们必须手动将类和方法从一个分支移动到另一个分支，然后再合并回来(大多数RCS只能在一个方向上维护子集-超集-关系)。因为方法可以以任何顺序出现在类中的任何位置，所以合并是一场噩梦。从一开始就强制对成员进行自动排序将会避免很多痛苦。

另一方面，如果在没有自动排序顺序的长期项目中工作，强制执行排序顺序可能不是一个好主意。到目前为止，移动所有成员基本上与丢弃版本控制是一样的，因为通过diff将文件与旧版本进行比较将不再有好处，原因与合并到另一个项目中是痛苦的原因相同。

如果应该进行重构，情况也是如此。当方法被重命名时，它们也将被移动，这使得两个版本的差异实际上毫无意义。有了不同的名称和不同的地方，很难再次识别方法。

Answer 1

考虑到您的IDE可以按您喜欢的方式对成员进行排序，我个人会避免在这件事上制定全球性的公司政策。

我认为，为了规则而制定规则是抑制团队动力的一个重要因素。作为程序员，我们有一种特定的心态，一种看待世界的特定方式。实用主义和实用主义通常比政策更受许多程序员的重视。

如果只是快速点击几个菜单项，让代码看起来像你想要的那样，当轮到你看它的时候，我会坚持这几次点击。(为方便起见，请将其转换为快速键盘快捷键)

Answer 2

我喜欢有一个一致的代码布局，但我已经痛苦地认识到，任何只涉及“编码风格”主题的东西都会导致无休止的讨论，并且会浪费很多时间。这是不值得的。

更重要的是在其他主题上做出决定(架构和设计，测试，如何沟通)。

通常，我倾向于假设随着时间的推移，相关的成员将被分组在一起。我不认为按字母顺序排序有什么好处，因为这是IDE可以为我做的事情。

重命名，移动代码，删除绿色代码，添加注释都不是我喜欢看到的与其他变化混合在一起的东西。这就是为什么我通常把它分成两个变化--一个是更新“代码布局/风格”，另一个是改变程序的行为。

Answer 3

对我来说..。我认为按访问级别排序很有用。我遵循StyleCop规则(.net，但在任何其他语言中都有效)

公共的

内部

受保护的内部

受保护

私有

静态

非静态

在这个小组里。我有一些随机性，但我总是把Id或唯一标识符之类的东西放在第一位。

我并不是说这是世界上更好的实践，但至少人们知道在哪里寻找东西。

根据您选择的长度和IDE，也许您可以幸运地找到一个工具，它可以根据您自己的偏好为您重新排列代码。(Resharper，对我来说，这是一个很好的帮助)