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

时间:2009-05-24 19:57:02

标签: version-control

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

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

是的,您可以拥有编码标准。大多数人都觉得它们很可怕。一个解决方案,每个人都可以吃蛋糕,吃它也似乎更合适。

======

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

我从中得到的是:

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

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

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

听起来像一个计划。再次感谢。

6 个答案:

答案 0 :(得分:5)

Git确实有以下选择:

  • --ignore-space-at-eol

    忽略EOL中的空白变化。

  • -b, --ignore-space-change

    忽略空白量的变化。这忽略了行尾的空格,并考虑了一个或多个的所有其他序列    空白字符是等价的。

  • -w, --ignore-all-space

    比较线条时忽略空格。即使一行具有另一行所在的空白,这也会忽略差异    无。

我不确定使用Git的差异是否可以忽略大括号更改。

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

答案 1 :(得分:5)

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

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

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

答案 2 :(得分:2)

也许您应该在登记前选择一种格式并运行一些缩进工具,以便每个人都可以签出,重新格式化他/她自己的偏好,进行更改,重新格式化回官方标准,然后签入?

一些额外的步骤,但他们在工作时已经使用了缩进工具。也许它可以是一个触发的登记脚本?

编辑:这也许也可以解决支撑问题。

(我自己没有尝试过这个解决方案,因此是“perhapes”和“maybes”,但我一直处于同样问题的项目中,尝试通过数百个无关的更改来完成差异是一种痛苦不限于空格,但包括格式本身。)

答案 3 :(得分:0)

Subversion显然支持这一点,无论是在最新版本中,还是使用像Gnu Diff这样的备用差异。

答案 4 :(得分:0)

Beyond Compare做了这个(以及更多),你可以将它作为外部差异工具集成到Subversion或Sourcesafe中。

答案 5 :(得分:0)

正如Is it possible for git-merge to ignore line-ending differences?中所解释的那样,将正确的差异工具与您最喜爱的VCS相关联更为重要,而不是依赖于正确的VCS选项(即使Git确实有一些关于空白的选项,比如Alan's answer中提到的一个,它将永远不会像人们想的那样完整。)

DiffMerge在“忽略”选项上更完整,因为它不仅可以忽略空格,还可以根据给定文件中使用的编程语言忽略其他“变体”。