代码格式和源代码控制差异

Question

在计算签入版本之间的差异时,哪些源代码控制产品具有忽略空格,大括号等的"差异"功能？我似乎记得Clearcase的差异做了这个,但Visual SourceSafe(或至少我使用的版本)没有.

我问的原因可能很典型.团队中四个完全合理的开发人员有四种完全不同的格式化代码的方式.在检查出其他人最后更改的代码后,每个人都会立即运行某种程序或编辑器宏来按照他们喜欢的方式格式化.他们进行实际的代码更改.他们签入他们的更改.他们去度假.两天后,这个已经运行两年的计划爆炸了.分配给bug的开发人员在版本之间进行差异,并发现204个差异,其中只有3个具有任何重要性,因为差异算法是蹩脚的.

是的,你可以有编码标准.大多数人都觉得它们很可怕.一个解决方案,每个人都可以吃蛋糕,吃它似乎更好.

=========

编辑:感谢大家提出一些很好的建议.

我从中得到的是:

(1)具有插入式差异的源控制系统是优选的.

(2)找到具有合适选项的差异.

(3)使用良好的源格式化程序并确定签入标准.

听起来像是个计划.再次感谢.

Answer 1

Git确实有这些选项:

• --ignore-space-at-eol

  忽略EOL中的空白更改.

• -b, --ignore-space-change

  忽略空格量的变化.这会忽略行尾的空格,并将一个或多个空白字符的所有其他序列视为等效.

• -w, --ignore-all-space

  比较线条时忽略空格.即使一行有空格而另一行没有空格,这也会忽略差异.

我不确定使用Git的diff可以忽略大括号的变化.

如果是C/C++代码,您可以使用Astyle定义Astyle规则,然后将源代码的大括号样式转换为您想要的样式.git diff然后A 将产生合理的输出.

Answer 2

选择一个(可怕的)编码标准,在一些官方编码标准文档中写下来,继续你的生活,搞乱空白是不富有成效的工作.

并且记住你是一个专业的开发人员,你的工作是完成项目,改变代码中的任何东西,因为个人风格偏好伤害项目 - 它不仅会使差异变得更加困难,它还会引入难以发现的问题如果您的源格式化程序或编译器有错误(当两个同事开始争夺套管时,您的花哨差异工具将无法保存您).

如果有人不同意使用所选择的风格,只是提醒他(或她)他是一个专业编程而不是业余爱好,请参阅http://www.ericsink.com/entries/No_Great_Hackers.html

Answer 3

也许您应该选择一种格式并在签入之前运行一些缩进工具，以便每个人都可以签出，根据自己的喜好重新格式化，进行更改，重新格式化回官方标准，然后签入？

有几个额外的步骤，但他们在工作时已经使用了缩进工具。也许它可以是触发的签入脚本？

编辑：这也许也能解决支撑问题。

（我自己没有尝试过这个解决方案，因此有“也许”和“也许”，但我一直在遇到同样问题的项目，尝试通过数百个不相关的更改进行差异是一种痛苦。仅限于空格，但包括格式本身。）