ReSharper代码清理功能（启用“reorder members”和“reformat code”非常棒。）使用XML定义布局模板，然后根据您在模板中设置的规则，重新组织整个源文件（或文件夹/项目/解决方案）。
无论如何，你认为这可能是关于VCS的问题，如颠覆，cvs，git等？是否有可能导致许多不良冲突？
谢谢。
答案 0 :(得分：16)
是的，肯定会引起问题。除了创建必须手动解决的冲突之外，当您签入已重新格式化的文件时，VCS会将几乎所有行都记录为已更改。这将使你或队友很难回顾历史，看看发生了什么变化。
也就是说，如果每个人都以相同的方式自动编码他们的代码（即，您将该XML模板分发给团队），那么它可能会运行良好。只有当不是每个人都做同样的事情时，问题才真正出现。
答案 1 :(得分：7)
我正在等待一个IDE或编辑器，它总是使用一些基线格式化规则来保存源代码，但允许每个开发人员以他们自己喜欢的格式显示和编辑代码。这样我就可以把我的开口花括号放在下一行的开头而不是当前行的末尾，你所有的异教徒似乎都认为它会去。
我的猜测是我会等很长时间。
答案 2 :(得分：7)
答案 3 :(得分：2)
它肯定会引起冲突，所以如果有人同时处理它们，我会确保你不重新格式化整个文件。
答案 4 :(得分：2)
您可以使用StyleCop来强制执行一套全面的标准，这些标准几乎迫使每个人使用相同的布局样式。然后，您需要做的就是开发一个与此匹配的ReSharper代码样式规范，并将其分发给团队。
我还在等待someone else to do this，并且让JetBrains清除所有不完全支持的琐碎细节，以便让ReSharper基本上保证完全符合StyleCop。
答案 5 :(得分：0)
这肯定会引起冲突。
如果要在多用户环境中使用它，那么Resharper的配置需要将代码格式化为一组标准，这些标准在组织中强制执行，无论用户是否使用Resharper。
通过这种方式，您可以使用该工具确保自己的代码符合标准，而不是将您的偏好应用于整个代码库。
答案 6 :(得分：0)
我同意以前的答案，说明冲突是可能的，甚至是可能的。
如果您计划重新格式化代码，那么至少要确保不要将重新格式化签名与更改实际代码功能的签名混合使用。通过这种方式，人们可以跳过简单重新格式化的过去签到。这也是一个好主意，以确保每个人都知道重新格式化即将到来，以便他们可以反对，如果他们在该领域正在进行的工作。
答案 7 :(得分：0)
答案 8 :(得分：0)
编写脚本来检查源代码管理历史记录中的每个版本，应用代码清理，然后将其检入新的存储库可能是个好主意。然后将该存储库用于将来的所有工作。