班级成员应该排序吗？
在新团队的新项目中，我们是否应该在签入之前强制按照特定顺序（例如按修饰符和字母表）自动对类成员进行排序？
另一种方法是让每个开发人员按照自己的想法对成员进行分组。由于每个人对相关内容和分组方式都有不同的看法，因此这几乎可以归结为随机顺序。
那么自动排序有哪些优点和缺点呢？这是否绑定到特定的 IDE/开发过程/构建过程/语言？我们还需要考虑什么？
编辑以提供更多答案：
我曾经参与过一个项目，我们必须维护多个分支。由于 RCS 无法适当地支持这一点（当时是 SVN），我们必须手动将类和方法从一个分支移动到另一个分支，然后再次合并回来（大多数 RCS 只能在一个分支中维护子集-超集-关系）方向）。由于这些方法可以以任何顺序出现在类中的任何位置，因此合并是一场噩梦。从一开始就强制对成员进行自动排序可以避免很多痛苦。
另一方面，如果在一个长期存在的项目中工作而没有自动排序顺序，则强制执行此操作可能不是一个好主意。到目前为止，移动所有成员基本上与放弃版本控制相同，因为通过 diff 将文件与旧版本进行比较将不再有效，原因与合并到其他项目是一件痛苦的事情相同。
如果需要重构，情况也是如此。当方法被重命名时，它们也将被移动，这使得两个版本的差异实际上毫无意义。由于名称不同、地点不同，很难再次识别方法。
On a new project with a new team, should we enforce to sort the members of the classes automatically in a specific order (e.g. by modifier and alphabet) prior to check-in?
The alternative is to let each developer group the members as he thinks. And since everyone has a different opinion of what is related and how the grouping should be, this pretty much comes down to random order.
So what are the pros and cons of having them sorted automatically? Is this bound to a specific IDE/development-process/build-process/language? What else do we have to consider?
Edit to foster more answers:
I once was in a project where we had to maintain several branches. Because of the inability of the RCS to support this appropriately (SVN by the time), we had to manually move classes and methods from one branch to another and than merge back again (most RCS can maintain a subset-superset-relation only in one direction). Because the methods could appear anywhere in the class in any order, merging was a nightmare. Enforcing automatic sorting of members right from the beginning would have avoided much of the pain.
On the other hand, if working in a long existing project without automatic sort order, it can be a bad idea to enforce this. Moving all the members around is basically the same as throwing away the versioning up to this point, because comparing files with older versions via diff will be no good anymore for the same reason that merging in the other project was a pain.
Same goes if refactoring is due. When methods are renamed they will also be moved, making a diff of two versions practically pointless. With different names AND different places, it is difficult to recognize methods again.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
鉴于您的 IDE 可以按照您喜欢的方式对成员进行排序，我个人会避免在此事上采用全球公司政策。
我认为为了规则而制定规则是降低团队积极性的一个重要因素。作为程序员，我们有一定的心态，有一定的看待世界的方式。许多程序员通常对实用性和实用主义的重视程度高于政策。
如果只需快速单击几个菜单项即可让代码在轮到您查看时按照您想要的方式显示，那么我会坚持这几次单击。 （为了方便起见，将其设为快速键盘快捷键）
Given that your IDE can sort your members the way you prefer, I'd personally avoid a global company policy on the matter.
I think rules-for-rules-sake are an important factor in de-motivating a team. As programmers we have a certain mindset, a certain way of seeing the world. Practicality and pragmatism are often valued higher by many programmers than policy.
If it's a quick click of a couple of menu items to have the code look the way you want it to when it's your turn to look at it, I'd stick with those few clicks. (and make this into a quick keyboard shortcut for your convenience)
我喜欢有一致的代码布局，但我已经惨痛地认识到，任何只涉及“编码风格”主题的事情总是会导致无休止的讨论，并且会浪费大量时间。这是不值得的。
更重要的是对其他主题（架构和设计、测试、如何沟通）做出决定。
通常我倾向于假设相关成员会随着时间的推移被分组在一起。我认为使用字母顺序排序没有任何优势，因为这就是 IDE 可以为我做的事情。
我不喜欢看到重命名、移动代码、删除绿色代码、添加注释与其他更改混合在一起。这就是为什么我通常将其分为两个更改 - 一个是更新“代码布局/样式”，另一个是更改程序的行为。
I like to have a consistent code layout, but I have learned the hard way that anything which only touches the topic of "coding style" always leads to endless discussions and can waste a lot of time. It is not worth it.
Far more important is to make decisions on other topics (architecture and design, tests, how to communicate).
Usually I tend to assume that related members will be grouped together over time. I see no advantage in using an alphabetical sort order, because that is what the IDE can do for me.
Renaming, moving code, deleting green code, adding comments is nothing I like to see mixed with other changes. That is why I usually split it into two changes - one, that updates the "code layout/style" and another, which changes the behaviour of the program.
就我而言......我认为按访问级别排序很有用。我遵循 StyleCop 规则（.net，但在任何其他语言中均有效）
Public
内部
受保护的内部
受保护
私有
静态
非静态
在这个组的内部...我有一些随机性，但我总是把诸如 Id 或唯一标识符之类的东西放在第一位。
我并不是说这是世界上最好的做法，但至少人们知道在哪里寻找东西。
根据您选择的语言和 IDE，也许您可能会幸运地找到一个可以根据您自己的喜好重新排列代码的工具。 （Resharper，就我而言，这是一个很好的帮助）
In my case... I consider usefull to order by access level. I follow the StyleCop rules (.net but valid in any other languaje)
Public
Internal
Protected Internal
Protected
Private
static
non-static
Inside of this groups... I've some randomness, but I always put things like Id's or unique identificator first.
I'm not saying this is the better good practice in the word, but at least people know where to look for things.
Depending of the lenguaje and the IDE you choose, maybe you could be lucky and find a tool that rearange the code for you based on your owns preferences. (Resharper, in my case, It's a good help)
我认为，如果类成员的排序可以提高代码的可读性，那么它很有用。排序方案不应该太严格，但要足够严格以提高代码的可读性。我更喜欢这种排序方案：
每个调用另一个方法（大部分是私有的）的方法，被调用的方法应该位于调用方法的下面。
正如上面所指出的，对类成员进行排序的唯一原因应该是更好的可读性，因为您编写一次代码，但会阅读一百次，因此拥有一个（团队）接受的排序系统可以提高生产力。
订购代码来解决 RCS 的缺陷本身不会带来更好的可读性，因此不会提高生产力。在大多数情况下，这样的排序方法会失败。我怀疑字母顺序方法是否可以带来更好的可读性。
I consider sorting of class members useful if it results in better readability of code. A sorting scheme should not be too strict but strict enough to add to better code readability. I prefer this sorting scheme:
Each method that calls another method (mostly private) the called method should be below the calling method.
As pointed out above the only reason to order class members should be better readability because you write code once but read it a hundred times, so having an accepted (by the team) order system can boost productivity.
Ordering code to work around inabilities of RCS will not per se lead to better readability and thus will not boost productivity. In most cases such an ordering method will fail. I'm in doubt if an alphabetic order method could lead to better readability.