我应该使用 Resharper 来整理其他人的代码吗？答案

【问题标题】：Should I use Resharper to tidy up other peoples code?我应该使用 Resharper 来整理其他人的代码吗？
【发布时间】：2009-10-02 19:11:22
【问题描述】：

我在工作中使用 Resharper。我的一些同事没有。

当我打开一些由其他人编写的代码时，我的屏幕上的橙色数量立即显而易见。

我不确定的是，我应该在多大程度上随意收拾那些在不知不觉中留下的烂摊子。对于我所看到的大部分内容，它是草率但无害的，如果我没有使用过 Resharper，它就不会真正跳出来。

我想我认为我的选择范围很广

1) 源代码更改历史对于维护至关重要。尽可能少地改变，否则下一个人不会有希望弄清楚发生了什么变化。无论如何，谁在乎无法访问的代码，不必要地使用 .ToString() 等等。

2) 更改无意义的内容，例如包含、修复方法文档 cmets 等。写它的人喜欢他的代码看起来像这样，所以让它保持在他不会抱怨的状态，但去掉一些不必要的橙色

3) 橙色只是红色，但颜色较浅。 F12 然后 Alt+Enter 直到绿色。

4) 忘了橙色，看看那个怪物 700 线函数。这是什么1997？是时候开始忙碌了……如果您有时间，请将您的同事介绍给我们的好朋友兼导师 Fowler 先生。

我倾向于在选项之间来回切换，具体取决于我有多少时间、我现在对代码负责的程度以及代码看起来有多复杂（这通常会让我选择 1 或 4）。

似乎 4 个选项中的一个应该是我正在努力的一个，但我不知道是哪一个

【问题讨论】：

似乎您只是在尽可能地回答自己的问题。
也许我不应该在喝完一瓶酒后发表评论，但在我看来，人们似乎更担心冒犯他们的“队友”而不是 700 行功能？看起来酒精把我变成了一个纯粹的混蛋。
是的！使用 Resharper 清理其他人的代码，尤其是当您将 Resharper 保留为默认设置并删除他们所有漂亮的 cmets 时。

标签： .net refactoring resharper maintainability

【解决方案1】：

"Leave the campsite cleaner than you found it."

这是童子军原则。如果它是“他们的”代码并且他们维护它，那么引入少量的清理更改不应该冒犯他们，但走得太远可能看起来很粗鲁，或者您可能实际上是在获得代码的所有权。

【讨论】：

我最近无意中听到一位开发人员说“好吧，我真的帮不了你。自从我上次查看代码以来，代码已经完全改变了”。我认为谁拥有未来的所有权是一个很好的观点
@Modan，我建议您用“var”替换显式类型声明（通过清理整个解决方案）并恶毒地嘲笑它们。他们喜欢它！ :)
也就是说，resharper 有时想将复杂的forEach 构造变成一个又大又长且难以阅读的 Linq 行。每当它想要这样做时，我都会通过注释关闭通知并添加注释，说明下面的代码不如 Linq 可读。
小范围的清理工作是团队合作可以做的最聪明的事情。为什么要让代码保持草率状态，尤其是当您可以使用 ReSharper Hints 轻松快速地重构小部分时……例如使用 ??或 ?: 等或删除不必要的 else 语句。如果有的话，这只会使代码更具可读性……更少的代码行意味着更易于维护。更清洁总是更好，因此团队应始终为之奋斗。否则，企业永远不会给你那个“项目去”。童子军规则适用于任何东西，而不仅仅是代码。
代码更改...处理它。否则，如果您不能介入并处理更改，那么您就不是开发人员……如果该代码已更改为更好，更易于阅读，或者您应该邀请此更改，而不是谴责它。当你可以在不破坏任何东西的情况下重构那只小狗时，为什么还要阅读一个 100 行的方法呢？应该不会被质疑。

【解决方案2】：

您的团队应该就标准达成一致。如果其他人使用其他工具，您可能会发现自己陷入了一场无意的编辑战。

但如果你们都同意，那么可以。随时清理代码。

【讨论】：

【解决方案3】：

在更改任何实际逻辑之前，我会进行“重新格式化”检查，这样您就可以看到发生了什么变化。

【讨论】：

这对于 diff 来说很好，但是当你去做一个 SVN Blame 看看是谁做了什么改变时，你的名字会无处不在。
@Alan :) 我认为这个想法是团队中的每个人都应该在签到之前重新格式化。
您始终可以使用提交挂钩将提交的代码与通过格式化程序运行的相同代码进行比较。如果两者不相同，则提交失败并发出通知。这确保了所有代码在提交之前都会被格式化（或者你的开发人员会抱怨和抱怨，然后弄清楚如何绕过这个钩子）。

【解决方案4】：

不必要的重构就是这样 - 不必要的。它会使存储库历史日志变得混乱，并且您可以引入错误。

如果“无意义”的东西（文档、cmets 等）应该以某种方式格式化，并且不符合您的开发标准，那么我会在尽可能少的签入中一次性完成。

当您实际处理代码片段并有机会测试您的更改时，请进行重构。 Resharper 将随时为您指明方向。

【讨论】：

是的，但并不是每个人都以同样的方式关心代码。可以这么说，有些人完全满足于“在他们吃的地方拉屎”。
经理不应该让人们在吃饭的地方拉屎。如果您对团队中的代码质量有疑问，最好的方法是与您的经理讨论这件事，而不是告诉其他人您认为他们的工作很糟糕（并且您的工作更好）代表他们重构它。
@Jason - 是的。我可以添加“代表他们不必要地重构它”。除非他们的代码存在已确定的问题（错误、代码标准问题等），否则重构它是没有必要的，而且不管它对作为编码员的你个人有多大的冒犯。

【解决方案5】：

如果你的团队中的开发工具不一样，最终会有更多的麻烦。按照上面建议的“重新格式化”检查并与您的同事一起标准化工具集，要么放弃 resharper，要么给每个人格式化魔法棒。

【讨论】：

【解决方案6】：

任何时候你改变任何东西，无论意图如何，你都有可能无意中破坏某些东西。就个人而言，如果不先与他人交谈，我不会更改他人的代码。

【讨论】：

【解决方案7】：

我建议仅在需要时更改内容。当然，对于“需要”的含义，有一些不同的定义。例如，如果您编写了一个调用另一个方法的方法，而您正在调用的这个方法恰好有一些代码重复？我会重构它，虽然我在删除多余的 using 语句等。我会尽量避免“仅仅因为”对整个代码库进行大规模重构。

【讨论】：

【解决方案8】：

如果已经签入，请小心。有些人会变得非常敏感，如果您的团队中的某个人仍在使用十年前无法在差异期间禁用空白检测的工具，这被认为是粗鲁的。

一般来说，当我出于其他原因接触代码时，我会清理代码样式以使其符合既定的组织样式目标。然而，请记住风格就是风格，因此没有“一条真正的道路”。不要因为你不喜欢同事使用的空格比你少（或多）而树敌。

【讨论】：

我的 GNU diff 版本是在 2002 年构建的（还差 3 年，但仍然如此），它可以很好地检测和忽略空格，谢谢。我设置 SVN 以使用该特定差异，一切都很好。
有时空白很重要，所以不是每个人都喜欢关闭空白检测。（顺便说一句，我的差异工具是 1996 年的，它也可以忽略空格。）

【解决方案9】：

我的建议是，如果您进行重新格式化，将其与任何代码修改分开进行。这样做的原因是您可以在存储库中将其标记为“仅重新格式化”，并且合法的代码更改不会隐藏在一堆间距更改的中间，从而使您或下一个人无法弄清楚是什么损坏了.

【讨论】：

【解决方案10】：

正如大多数人已经说过的那样，是的，最好重构并保持整洁。

重构可以帮助每个人变得更好，每个人都应该可以使用重构工具（对我来说是 Coderush）。

但是，如果您的同事没有分享重构的热爱，那么这是您启发他们的好机会 :)

【讨论】：