11

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

当我打开一些不是别人写的代码时，我的屏幕上的橙色量立即显而易见。

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

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

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

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

3）橙色只是红色但更轻。F12 然后 Alt+Enter 直到绿色。

4）忘掉橙子，看那个怪物700线功能。这是什么1997？是时候忙碌起来了……如果您有时间，请将您的同事介绍给我们的好朋友兼导师福勒先生。

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

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

4

10 回答 10

17 
"Leave the campsite cleaner than you found it."

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

于 2009-10-02T19:44:02.277 回答
15

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

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

于 2009-10-02T19:17:01.160 回答
6

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

于 2009-10-02T19:14:05.597 回答
5

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

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

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

于 2009-10-02T19:20:42.760 回答
2

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

于 2009-10-02T19:18:19.003 回答
2

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

于 2009-10-02T19:31:25.657 回答
2

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

于 2009-10-02T19:24:51.037 回答
1

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

于 2009-10-02T19:40:06.510 回答
1

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

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

于 2009-10-02T19:20:17.520 回答
1

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

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

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

于 2009-10-20T13:37:00.980 回答