我在工作中使用Resharper。我的一些同事没有。
当我打开一些已经写过但没有写过的代码时,我的屏幕上显示橙色的数量就会很明显。
我不确定的是,我应该在多大程度上自由地整理那些在不知不觉中留下的混乱。对于我所看到的大部分内容,它是草率但无害的,如果我从未使用过Resharper,就不会真的跳出来。
我想我的选择大致是
1)源代码更改的历史记录对于维护至关重要。尽可能少地改变,或者下一个人不希望弄清楚改变了什么。谁关心无法访问的代码,无论如何都不必要地使用.ToString()等。
2)更改无意义的内容,例如包含,修复方法文档注释等等。写它的人喜欢他的代码看起来像这样,所以把它留在他不会抱怨的状态,但摆脱一些不必要的橙色
3)橙色只是红色但更轻。 F12然后按Alt + Enter直到绿色。
4)忘记橙色,看看那个怪物700线功能。这是什么1997年?是时候忙碌......如果你有时间,请把你的同事介绍给我们的好朋友和导师福勒先生。我倾向于在选项之间徘徊,具体取决于我有多少时间,我现在负责代码的程度,以及代码看起来有多复杂(通常可以让我选择1或4)。 / p>
看起来四个选项中的一个应该是我正在努力的那个,但我不知道哪一个
答案 0 :(得分:17)
"Leave the campsite cleaner than you found it."
这是boyscout原则。如果它是“他们的”代码并且他们维护它,那么引入一些清理改变不应该冒犯它们,但是走得太远可能看起来很粗鲁,或者你可能有效地获得了代码的所有权。
答案 1 :(得分:14)
您的团队应该就标准达成一致。如果其他人使用其他工具,您可能会发现自己处于无意的编辑战争中。
但如果你们都同意,那么是的。随时清理代码。
答案 2 :(得分:6)
在更改任何实际逻辑之前,我会进行“重新格式化”检查,这样您就可以看到发生了哪些变化。
答案 3 :(得分:5)
不必要的重构只是 - 不必要。它使存储库历史记录日志变得混乱,您可以引入错误。
如果“无意义”的东西(文档,评论等)应该以某种方式格式化,并且它不符合您的开发标准,那么我会尽可能少地签入所有内容。
当您实际处理这些代码并有机会测试您的更改时,请进行重构。 Resharper将随时为您指明道路。
答案 4 :(得分:2)
如果团队中的开发工具不尽相同,那么将会遇到更多麻烦。按照上面建议的“重新格式化”办理登机手续,与同事一起标准化工具集,或者放弃resharper,或者给每个人一个格式化魔术棒。
答案 5 :(得分:2)
任何时候你改变任何东西,无论意图如何,你都有可能无意中破坏某些东西。在个人方面,我不会在没有与他们交谈的情况下改变他人的代码。
答案 6 :(得分:2)
我建议您只在需要时更换东西。当然,对“需要”的含义有一些不同的定义。例如,如果你编写一个调用另一个方法的方法,并且你调用的这个方法碰巧有一些代码重复?我会对它进行重构,而在我删除它时会删除多余的using
语句等等。我会尽量避免整个代码库的大规模重构“仅仅因为”。
答案 7 :(得分:1)
如果已经签入,请小心。有些人非常敏感,如果团队中的某个人仍在使用十年前的工具,并且在差异期间无法禁用空白检测,则会被视为粗鲁。
一般情况下,当我因为其他原因触摸代码时,我会清理代码样式以使其符合规定的组织样式目标。但要记住,风格是风格,因此没有“一种真正的方式”。不要制造敌人,因为你不喜欢同事使用比你更少(或更多)的空白这一事实。
答案 8 :(得分:1)
我的建议是,如果你进行重新格式化,它将与任何代码修改分开进行。这样做的原因是你可以在存储库中将其标记为“仅重新格式化”,并且合法的代码更改不会隐藏在一堆间距变化的中间,这使得你或下一个人无法弄清楚是什么打破了
答案 9 :(得分:1)
正如大多数人已经说过的那样,更好的是重构并让它更整洁。
重构有助于每个人都变得更好,每个人都应该有权访问重构工具(Coderush对我来说)。
然而,如果你的同事没有分享重构的爱,那么这是一个很好的机会让你启发他们:)