logo标签列表

我应该使用Resharper来整理别人的代码吗？

.netrefactoringresharpermaintainability
11

我在工作中使用Resharper，但有些同事不使用。

当我打开一些被不使用Resharper的人编写的代码时，屏幕上的橙色数量立即让我知道这一点。

我不确定应该在多大程度上自由地整理他们无意留下的混乱。对于我正在查看的大部分内容而言，它虽然看起来杂乱无序，但并没有什么实际的危害。如果我以前从未使用过Resharper，也不会很明显。

我认为我的选择主要有：

1）源代码的更改历史对于维护是必不可少的。尽可能少地更改，否则下一个人将无法弄清楚发生了什么变化。反正谁关心那些无法到达的代码、不必要的使用.ToString()等。

2）更改无用的东西，如包含文件，修复方法文档注释之类的东西。编写此代码的人喜欢他的代码看起来像这样，所以保持它处于一个不会引起抱怨的状态，但同时去掉一些不必要的橙色。

3）橙色只是浅红色。按F12，然后按Alt+Enter直到变成绿色。

4）忘了橙色，看看那个700行的怪物函数。这是1997年吗？是时候开始动手了...如果有时间的话，向你的同事介绍我们的好朋友和导师Fowler先生。

通常我会根据我有多少时间、我现在对代码负责到什么程度以及代码的复杂程度（通常使我选择1或4）来在以上选项之间做出选择。

似乎应该努力实现以上四种选项之一，但我不知道应该选择哪一个。

似乎你正在通过尽力而为来回答自己的问题。 - thepaulpage
2
也许我喝了一瓶酒之后不应该发表评论，但是对我来说，人们似乎更担心冒犯他们的“队友”而不是那个有700行的函数，这看起来像是酒精让我变成了一个纯粹主义者。 - Modan
<sarcasm>是的！使用Resharper来清理别人的代码，特别是当你将Resharper保留在默认设置并剥夺了他们所有漂亮的注释时。</sarcasm> - Chris O
10个回答
17
"Leave the campsite cleaner than you found it."

这就是童子军原则。如果代码是"他们"的，而且他们正在维护它，那么引入一些小的清理更改不应该冒犯他们，但是走得太远可能会显得粗鲁，或者你可能有效地占据了代码所有权。

3
最近我听到一个开发人员说：“我真的帮不了你了。自从我上次查看代码以来，它完全改变了。” 我认为谁将负责未来的所有权是一个非常重要的问题。 - Modan
@Modan，我建议你用“var”代替显式类型声明（对整个解决方案进行清理），然后恶魔般地对它们大笑。他们会喜欢的！ :) - Arnis Lapsa
话虽如此，Resharper有时会想把一个复杂的forEach结构转换成一个又长又难以阅读的Linq语句。 每当它这样做时，我会通过注释关闭通知，并添加一条说明，说明下面的代码作为Linq不太易读。 - Timothy Groote
小清理是团队可以共同做的最聪明的事情。为什么要保持代码处于松散状态，特别是当您可以使用ReSharper提示轻松快速地重构小部分时...例如使用??或?:等，或删除不必要的else语句。如果有的话，这只会使代码更易读...更少的代码行意味着更容易维护。更干净总是更好的，因此团队应始终努力实现它。否则，业务永远不会给您“项目进行”。男童军规则适用于任何东西，而不仅仅是代码。 - PositiveGuy
2
代码变更...要处理它。否则，如果你不能跳进去处理变化，那你就不是一个开发者...如果那段代码已经变得更好、更易读或者其他方面有所改进，那么你应该欢迎这种变化，而不是谴责它。为什么要阅读一百行的混乱方法，当你可以重构它而不会破坏任何东西呢？这应该是被期望而不是被质疑的。 - PositiveGuy
15

你的团队应该达成一个标准。如果其他人使用另一种工具，你可能会陷入无意的编辑战中。

但是，如果你们都能达成一致，那么可以一边写代码一边进行清理。

6

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

4
这个 diff 看起来不错，但当你进行 SVN Blame 以查看谁做出了哪些更改时，你的名字将会无处不在。 - Alan
@Alan :) 我认为这个想法是团队中的每个人都应该在提交之前进行重新格式化。 - Dan
您可以始终使用提交钩子将提交的代码与通过格式化程序运行的相同代码进行比较。如果两者不相同，则提交失败并显示通知。这确保了在提交之前所有代码都将被格式化（或者您的开发人员会抱怨并找出如何绕过钩子）。 - BryanH
5
不必要的重构就是指不必要的。这会使代码库历史记录杂乱无章，并可能引入错误。
如果“无意义”的内容（文档、注释等）应该按某种方式格式化，而且它不符合您的开发标准，那么我建议您尽可能少地进行多次提交一次性完成。
当您实际上正在处理代码块并有机会测试更改时，请进行重构。此时，Resharper将始终可用以指导您的工作。
4
是的，但并非每个人都以相同方式关心代码。有些人完全满足于“在自己吃饭的地方拉屎”，这就是说。 - Ty.
2
管理者不应该让人们在吃饭的地方拉屎。如果你对团队中代码质量有问题，最好的方法是与你的经理谈论，而不是通过代表他们重构代码来告诉其他人你认为他们的工作很糟糕（而你的更好）。 - Jason Williams
2
@Jason - 是的。我可以补充一点，那就是“为他们不必要地重构代码”。除非存在已知问题（如错误、代码标准问题等），否则重构代码是毫无意义的，并且会增加工作量，无论你作为一名编码人员个人是否感到烦恼。 - womp
2

如果团队中的开发工具不同，最终会导致更多的麻烦。按照上面建议的“重新格式化”检入，并与同事们标准化工具集，要么放弃resharper，要么给每个人提供格式化魔棒。

2

无论你的意图如何，每当你改变任何东西时，都存在意外破坏的风险。个人而言，在未经他人同意之前，我不会修改别人的代码。

2

我建议只在需要时更改事物。当然，"需要"的定义有所不同。例如，如果您编写一个调用另一个方法的方法，并且您正在调用的这个方法恰好具有一些代码重复？我会进行重构，并在此过程中删除多余的using语句等。但我会尽量避免仅仅因为"无聊"而对整个代码库进行大规模重构。

1

如果已经进行了检查，请小心。有些人会变得非常敏感，如果你的团队中仍然有人使用十年前的工具且无法在差异中禁用空格检测，则被认为是粗鲁的。

通常情况下，当我因其他原因接触代码时，我会清理代码样式，使其符合所述组织样式目标。但请记住，风格只是风格，因此没有“一种真正的方法”。不要因为同事使用的空格比你少（或更多）而与他们产生敌意。

我的GNU diff版本是在2002年构建的（比十年少三年，但仍然可以），它可以很好地检测和忽略空格，谢谢。我设置了SVN来使用那个特定的diff，世界上一切都很好。 - BryanH
有时空格是有意义的，所以并不是每个人都喜欢关闭空格检测。（顺便说一下，我的差异工具来自1996年，它也可以忽略空格。） - MarkJ
1
我的建议是，如果您要重新格式化代码，请将其与任何代码修改分开进行。原因是您可以在存储库中将其标记为“仅重新格式化”，这样合法的代码更改就不会被埋在一堆间距更改中，从而使您或下一个人无法弄清楚哪里出了问题。
1
正如大多数人已经说过的一样，最好重构并使其更整洁。
重构有助于每个人变得更好，每个人都应该有访问重构工具（对我来说是Coderush）。
然而，如果你的同事们不分享重构的爱，那么这是一个让你启发他们的好机会 :)
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接