使用VCS时格式化代码是一件坏事吗？

在承诺确保正确完成之前，几乎总是格式化我的代码。我团队中的大多数人都不在乎，也不总是总是正确地格式化他们的代码（次要的事情不会影响代码，但是会在尝试维护代码时影响可读性）。

我最近安装了具有选项“保存时格式化”的VS电动工具，并对以前未格式化的文件进行了更改。开发副总裁只是来找我，并谴责我进行格式化，因为它在合并工具中显示为几乎整个文件都被更改了，而不是一两行（所以他看不到我很容易地修改了什么），并且告诉我以后禁用保存格式。尽管我了解这种担忧，但是我发现有时很难对未格式化的代码进行分类，而IMO应该始终始终对其进行正确格式化。请注意，我不仅随心所欲地重新格式化，而且在编写代码时，我将使用电动工具或按key命令设置文本格式以使其易于阅读，并且在SVN中显示为修改。

所以我问，总是格式化代码实际上是一件坏事吗？他的担忧是否比确保代码可读性更有效？

首先，您的团队需要选择一种格式约定并坚持使用。您需要达成协议并让每个人都遵守它，这样您才不会有人为事情的样子而战。这不应该只是您自己做的事情。

至于你真正的问题。格式化代码不是一件坏事。不好的是在与代码更改相同的提交中进行了主要的格式更改。当您的团队就应如何格式化内容达成共识时，请遍历代码并格式化所有内容。自行检查。提交消息将使您清楚地知道更改只是空白而不起作用。然后，当您需要进行功能更改时，它们处于不同的提交中，因此可以清楚地看到它们。

不，格式化代码非常重要。但是，提交应分为两类：

1. 装饰性更改 -使代码更具可读性的任何操作。
2. 其他更改 -影响代码的其他所有内容。

使用提交消息表示仅更改了化妆品。在搜索更重要的修改时，可以轻松地跳过这些内容。

你们都有观点，但是你们都能得到想要的。首先格式化代码，仅签入该更改。接下来，进行功能更改，并在第二步中进行检查。

我也正在格式化nit-picker，因此这里有一些提示：

• 必需的第一步：让团队就一些基本的格式标准达成一致，例如制表符与空格，大括号位置，注释样式等。现在，格式更改不会让所有人感到完全惊奇，也不会在任何脚趾上。

• 仅在您更改的代码周围清理格式。如果仅更改一项功能，则清理该功能。至少随着时间的流逝，您将获得外观更好的代码。

• 将主要格式检修作为单独的提交执行，而无需更改其他代码。仅当您不太希望在更改之后与更改之前比较代码时，才应执行这些操作，因为在这样的差异之间进行比较可能很烦人。通常，在对该代码进行重大开发之前，我通常会先进行清理。

• 获得一个好的差异工具，该工具可以对重大更改和非重大更改进行语言相关的标记。我最喜欢的差异也是Beyond Compare，它表示一种颜色的实际代码更改，而空白/注释仅另一种颜色的差异。

编辑更多提示：

• 它因语言而异，但是对于大多数真正的代码更改，您应该能够在大型清理之前和之后比较编译后的二进制文件，以确保您不会对其进行处理。

除非进行以下操作，否则您不应该重新设置格式并更改其他人的代码：

• 您是试图建立团队编码标准的经理
• 您的经理已要求您清理代码以符合团队编码标准
• 您正在从团队中的某个开发人员那里清除代码，以遵守团队编码标准。

在所有情况下，您都会注意到我指的是团队编码标准。我坚信团队会采用合理的，商定的编码标准。如果有它们，那么原始开发人员应该回去整理他或她的代码以符合团队标准，您不应该在他们的背后这样做。如果您没有标准（应该这样做），那么您就不应该修改另一位团队成员的代码以遵守自己的理念，尤其是在背后。请记住，您是团队的一部分，虽然编码标准很重要，但团队成员之间的信任和尊重也很重要。