重构他人源代码的礼仪？

Question

我们的软件开发团队由一群有经验、编程风格和喜好各异的程序员组成。我们并没有对所有事情都有标准，只有必要的标准以防止完全混乱。

最近，我遇到了一位同事进行的一些重构。我的代码看起来有点像这样：

public Person CreateNewPerson(string firstName, string lastName) {
    var person = new Person() {
        FirstName = firstName,
        LastName = lastName
    };
    return person;
}

这被重构为：

public Person CreateNewPerson (string firstName, string lastName) {
    Person person = new Person ();
           person.FirstName = firstName;
           person.LastName = lastName;
    return person;
    }

只是因为我的同事需要更新我编写的某个类中的其他方法，他也“重构”了上面的方法。值得记录的是，他是那些鄙视语法糖并使用不同括号放置/缩进方案的开发人员之一。

我的问题是：（C＃）程序员在重构其他人的源代码（语义和语法）方面的礼仪是什么？

- Prutswonder

---

你应该将这个设为社区共享页面。 - Lieven Keersmaekers

关于礼仪方面，最好的方式可能是直接面对他，让他知道你不喜欢他重构你的代码。你也可以更加巧妙地处理，回滚你的代码并修改他的代码以符合你的风格。虽然一开始这样做很有趣，但最终可能不会给你带来任何好处。 - Lieven Keersmaekers

我已将其还原为我的版本，并使用“改善代码一致性”注释将其检入 SVN。此后未进行任何更新。 当我向他提出时，他或多或少地承认这并不是真正必要的。因此，基本上，我们同意除非必须，否则不会触碰彼此的代码。 - Prutswonder

“agreed not to touch each other's code unless it is required” - 这是一个错误。你的团队需要解决这个问题，以便真正成为一个团队。建立每个人都能接受并遵循的标准，然后每个人都会朝着同一目标进行重构（实际上是重新格式化）。 - Carl Manaster

我会是那些将第二个版本重构为第一个版本的人之一... - Carra

我必须说，那是他进行的一次相当恶心的重构！ - Nick Bedford

Answer 1

我认为应该更关注经济方面而不是礼貌。每次代码更改都会引起大量成本:

• QA必须测试代码更改
• 开发人员必须编写测试套件以进行测试
• 可能需要记录影响用户体验的代码更改
• 代码更改可能会引入错误，这显然是巨大的成本
• 等等。

我绝不会对任何具有生产质量的代码进行仅限于美观方面的小改动，无论它是否属于我。这种改动的好处远远不足以证明其成本。

你可以考虑提醒你的同事，你们从事的是编码业务，而不是生产你们都认为美观的漂亮代码，而是为公司在疲软的经济环境下创造利润。你们不是艺术家，而是工程师，所以要像工程师一样行事；所有的改变都应该有商业目的来证明其合理性。

- Eric Lippert

Answer 2

我认为 集体代码所有权 是正确的，也就是说，代码属于项目，而不是某个工程师。因此，只要重构后的代码符合项目标准，我对他人对我的代码进行修改并没有问题。如果项目没有编码标准，则团队应该定义一些。

- Pascal Thivent

Answer 3

团队应该始终遵循一定的礼仪规范。因此，请与您的同事讨论此事，并与整个团队讨论以制定规则。

常见的规则可能包括不更改代码，如果只是为了美化和争议的编码风格。如果将来有人需要维护您的类，则通常可以更改任何内容。

定义一些基本规则、一些反模式（始终可以由您的同事重构）等等。

这些规则不必非常严格，因此不需要定义大括号或类似的东西的位置。但在这种情况下，没有人应该美化其他人维护的代码。如果您对某件事情产生冲突，请与整个团队进行讨论，以创建针对此情况的新规则。

- Mnementh

Answer 4

如果没有编码风格指南/规则，他可能甚至不会意识到这种变化会引起烦恼。

话虽如此，这种风格相当非标准化，在个人层面上，我会对"重构"感到烦恼，因为这并没有改变代码的含义，而只是用他自己的编码风格取代了你的风格。我甚至不确定它是否符合重构的标准。相当自私。

- spender

Answer 5

在我看来，这并没有使代码更加清晰易懂，只是将别人的编码风格强加到了它上面。你应该与你的同事讨论一下是否真的有必要进行这种“重构”（以及你的同事是否真的没有更好的方式来利用他/她的时间:-)）

- Péter Török

Answer 6

最重要的是保持一致性。您的团队应该决定是否使用类型推断和对象初始化器，并编写一些编码指南。

- Ozan

---

最佳答案在这里。如果团队或项目有编码标准，那么问题就是谁遵守了这个标准，谁没有。在制定标准时让争论发生。 - Dave Archer

此外：通过与同事的互动，您正在决定标准；到目前为止，您已经决定没有标准。这是一个问题。 - Carl Manaster

Answer 7

我认为最重要的是能够持不同意见但又做出承诺。我们都有自己的偏好，但在不重要的事情上来回更改只会浪费大家的时间。

- Brian Rasmussen

Answer 8

严格遵守标准。如果没有标准，那就是你的问题，而不是其他人可以并且会更改你的代码。

此外，在对代码更改感到不满之前，您需要确定意图。这是恶意更改还是无心之失？

- Andrew Lewis

Answer 9

如果我正在修改一个同事拥有的文件，我会尽量保持更改与他们的风格一致。这样，即使我们一半的文件为字段前缀“m_”，另一半为“_”（以及其他小细节），至少单个文件/类是自洽的。

- Dan Bryant

Answer 10

我认为在这个具体的例子中（即C#），你应该简单地遵循微软提供的指南。与.NET Framework的代码标准保持一致，可以使类和代码结构易于阅读。

另一件事是Visual Studio会在您输入时自动纠正各种格式规则，这将有所帮助。例如，在关闭括号或结束语句时。

我个人认为，美化重构看起来很丑，并降低了可读性，而你的代码遵循了.NET约定。

- Nick Bedford