我应该使用 Resharper 来整理其他人的代码吗？
我在工作中使用 Resharper。我的一些同事不这么认为。
当我打开一些由其他人编写的代码时，屏幕上的橙色数量立即显而易见。
我不确定的是，我应该在多大程度上自由地收拾那些不知不觉中留下的烂摊子。我所看到的大部分内容都是草率但无害的，如果我没有使用过 Resharper，也不会真正引起我的注意。
我想我的选择大致如下：
1）源代码更改的历史对于维护至关重要。尽可能少地改变，否则下一个人就没有希望弄清楚发生了什么变化。无论如何，谁关心无法访问的代码、不必要的 .ToString() 等。
2）更改无意义的内容，例如包含，修复方法文档注释之类的内容。写它的人喜欢他的代码看起来像这样，所以让它保持在他不会抱怨的状态，但要去掉一些不必要的橙色
3) 橙色只是红色但更浅。 F12，然后 Alt+Enter 直到绿色。
4）忘记橙色，看看那个怪物700行的功能。这是什么1997年？是时候忙碌起来了……如果您有时间，请将您的同事介绍给我们的好朋友兼导师福勒先生。
我倾向于根据我有多少时间、我现在对代码负责的程度以及代码看起来有多复杂（这通常会让我选择 1 或 4）来在选项之间切换。
看来这 4 个选择之一应该是我正在努力的一个，但我不知道哪一个
I use Resharper at work. Some of my colleagues do not.
When I open some code that has been written someone who doesn't, it is immediately obvious by the amount of orange on my screen.
What I am unsure of is to what extent I should feel free to tidy up the messes the have unknowingly left. With most of what I am looking at, it is sloppy but harmless, and wouldn't really jump out at me if I hadn't ever used Resharper.
I guess I see my options broadly as
1) The history of changes to source code is essential to maintenance. Change as little as possible, or the next guy wont have a hope of figuring out what has changed. Who cares about unreachable code, unnecessary use of .ToString() etc. anyway.
2) Change the meaningless stuff like includes, fix method documentation comments and things like that. The guy who wrote it likes his code to look like this, so leave it in a state where he wont complain, but get rid of some of the unnecessary orange
3) Orange is just red but lighter. F12 then Alt+Enter until green.
4) Forget the orange, look at that monster 700 line function. What is this 1997? Time to get busy... and if you have got the time, introduce your colleague to our good friend and mentor Mr Fowler.
I tend to flit between the options depending on how much time I have got, to what extent I am now responsible for the code, and how complex the code looks (which can make me go for 1 or 4 usually).
It seems like one of the 4 options should be the one I am striving for though, but I have no idea which one
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
您的团队应该就标准达成一致。如果其他人使用其他工具，您可能会发现自己陷入了无意的编辑战争。
但如果你们都同意，那就可以。边走边清理代码。
Your team should agree on a standard. If someone else uses another tool, you may find yourself in an unintentional edit war.
But if you can all agree, then yes. Clean up the code as you go.
在更改任何实际逻辑之前，我会进行“重新格式化”检查，这样您就可以看到发生了什么变化。
I do a "reformat" check in before changing any of the actual logic, this way you can see what has changed.
不必要的重构就是这样——没必要。它会使存储库历史日志变得混乱，并且可能会引入错误。
如果“无意义”的东西（文档、评论等）应该以某种方式格式化，并且不符合您的开发标准，那么我会在尽可能少的签入中一次性完成所有这些工作。
当您实际处理代码片段并有机会测试您的更改时，请进行重构。届时，Resharper 将随时为您指路。
Needless refactoring is just that - needless. It clutters up the repository history logs and you can introduce bugs.
If the "meaningless" stuff (documentation, comments, etc.) is supposed to be formatted a certain way, and it's not up to your development standards, then I would do it all at once in as few checkins as possible.
When you are actually working on the pieces of code and have the opportunity to test your changes, do the refactoring then. Resharper will always be available to show you the way at that point.
如果你团队中的开发工具不一样，最终会出现更多的麻烦。按照上面建议的“重新格式化”签入，并与同事一起标准化工具集，要么放弃 resharper，要么为每个人提供格式化魔杖。
If the development tools in your team are not the same eventually there will be even more trouble. Follow the "reformat" check-in suggested above and standardize the toolset with your colleagues, either drop resharper or give everyone the formatting magic wand.
任何时候你改变任何东西，无论意图如何，你都有可能无意中破坏某些东西。就个人而言，在没有先与他人交谈的情况下，我不会更改他们的代码。
Any time you change anything, regardless of the intent, you risk breaking something unintentionally. On a personal side, I wouldn't change another person's code without talking to them first.
我建议仅在需要时才进行更改。当然，对于“需要”的含义有一些不同的定义。例如，如果您编写一个调用另一个方法的方法，而您调用的这个方法恰好有一些代码重复？我会重构它，并在删除多余的
using语句等的同时，尝试避免“只是因为”对整个代码库进行大规模重构。I recommend only changing things when you need to. There is, of course, some varying definition on what "need" means. For example, if you write a method that calls another method, and this method you're calling happens to have some code duplication? I'd refactor that, and while I'm at it remove excess
usingstatements, etc. I'd try to avoid just a massive refactor of the entire codebase "just because" though.如果已经签入，请小心。有些人会变得非常敏感，如果你的团队中有人仍在使用十年前的工具，而这些工具无法在差异期间禁用空格检测，那么这会被认为是粗鲁的。
一般来说，当我出于其他原因接触代码时，我会清理代码样式，使其符合规定的组织样式目标。然而，请记住，风格就是风格，因此不存在“唯一正确的方法”。不要因为不喜欢同事使用比你少（或多）的空白而树敌。
If it's already checked in, be careful. Some people get awfully touchy and it's considered rude if someone on your team is still using tools from a decade ago that can't disable whitespace detection during a diff.
In general, I'll clean up code styling to bring it in line with the stated organization style goals when I'm touching the code for another reason. Try to remember that style is style, however, and as such there is no "one true way." Don't make enemies because you don't like the fact that a colleague uses less (or more) whitespace than you do.
我的建议是，如果您进行重新格式化，则应将其与任何代码修改分开进行。这样做的原因是，您可以在存储库中将其标记为“仅重新格式化”，并且合法的代码更改不会被埋在一堆间距更改的中间，从而使您或下一个人无法找出损坏的原因。
My suggestion would be that if you do a reformat that it be done separately from any code modifications. The reason for this is that you can mark it as "reformat only" in the repository and a legitimate code change will not be buried in the middle of a bunch of spacing changes making it impossible for you or the next guy to figure out what broke.
正如大多数人已经说过的那样，是的，最好进行重构并使其更加整洁。
重构可以帮助每个人变得更好，每个人都应该能够使用重构工具（对我来说是 Coderush）。
但是，如果您的同事不喜欢重构，那么这是您启发他们的好机会:)
As the majority of people have already said, yes, better to refactor and leave it tidier.
Refactoring helps everyone get better, and everyone should have access to the refactoring tools (Coderush for me).
However, if your colleagues aren't sharing the refactoring love, then it's a good opportunity for you to enlighten them :)
这是童子军原则。如果这是“他们的”代码并且他们维护它，那么引入小的清理更改不应冒犯他们，但走得太远可能看起来很粗鲁，或者您可能实际上获得了代码的所有权。
It's the boyscout principle. If it's "their" code and they maintain it then introducing little cleanup-changes shouldn't offend them, but going too far might seem rude or you might be effectively taking ownership of the code.