班级成员应该分类吗？

Question

在一个新团队的新项目中，我们是否应该在办理登机手续之前强制按特定顺序（例如通过修饰符和字母表）对班级成员进行排序？

另一种方法是让每个开发人员按照他的想法对成员进行分组。而且由于每个人对相关内容以及分组应该如何有不同的看法，这几乎归结为随机顺序。

那么让它们自动排序的优缺点是什么？这是否绑定到特定的IDE / development-process / build-process /语言？我们还需要考虑什么？

编辑以获得更多答案：

我曾经在一个项目中，我们必须维护几个分支机构。由于RCS无法正确支持（SVN到时间），我们不得不手动将类和方法从一个分支移动到另一个分支而不是再次合并（大多数RCS只能在一个中保持子集 - 超集关系）方向）。因为这些方法可以以任何顺序出现在类中的任何位置，所以合并是一场噩梦。从一开始就强制对成员进行自动分类可以避免很多痛苦。

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

如果重构到期，同样如此。当方法被重命名时，它们也将被移动，使得两个版本的差异几乎毫无意义。由于名称和地点不同，很难再次识别方法。

Answer 1

鉴于您的IDE可以按您喜欢的方式对您的成员进行排序，我个人会避免就此问题制定全球公司政策。

我认为规则规则是驱逐团队的重要因素。作为程序员，我们有一定的心态，一种看待世界的方式。许多程序员的实用性和实用主义往往比政策更高。

如果快速点击几个菜单项，让代码看起来就像你想要的那样，轮到你查看它时，我会坚持点击几下。 （为方便起见，将其变为快捷键盘快捷键）

Answer 2

我喜欢拥有一致的代码布局，但我已经学到了很难，只涉及“编码风格”主题的任何内容总会导致无休止的讨论并浪费大量时间。这不值得。

更重要的是就其他主题（架构和设计，测试，如何沟通）做出决策。

通常我倾向于假设相关成员会随着时间的推移而聚集在一起。我认为使用按字母顺序排序顺序没有任何优势，因为这就是IDE可以为我做的事情。

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

Answer 3

就我而言......我认为按访问级别排序很有用。我遵循StyleCop规则（.net但在任何其他语言中都有效）

公共
内部
受保护的内部
保护
私人

静态
非静态的

在这些群体中...我有一些随机性，但我总是把Id或者唯一识别器放在首位。

我不是说这是一个更好的做法，但至少人们知道在哪里寻找东西。

根据你选择的lenguaje和IDE，也许你很幸运，找到一个工具，根据你自己的喜好为你重新排列代码。 （Resharper，就我而言，这是一个很好的帮助）

Answer 4

我认为如果类成员的代码更易于阅读，那么对它们进行排序是有用的。排序方案不应该太严格，但要严格到足以增加更好的代码可读性。我更喜欢这种分类方案：

• 静态字段
• 实例字段
• 构造
• 方法

调用另一个方法（主要是私有）的每个方法都应该在调用方法之下。

如上所述，订购类成员的唯一原因应该是更好的可读性，因为您只需编写一次代码但读取一百次，因此拥有一个（通过团队）订单系统可以提升生产率。

订购代码以解决RCS的无形性本身不会带来更好的可读性，因此不会提高生产力。在大多数情况下，这种排序方法将失败。我怀疑字母顺序方法是否可以带来更好的可读性。