2010-04-06 91 views
4

我目前是组织内部实施新版本控制系统(Subversion)的一员。关于如何处理代码格式有一些争议,我希望得到其他人对这个主题的意见和经验。版本控制和编码格式

我们目前拥有约10位开发人员,每个开发人员使用不同的工具(由于许可和偏好)。其中一些工具具有自动代码格式化程序,而另一些则不具备。

如果我们允许“盲注”签入,每次有人进行签入时代码都会显得截然不同。这会使差异和合并变得复杂。

我接触过的几个人,他们已经提到了以下解决方案:

  1. 与使用相同的代码格式相同的开发者计划(不是真的由于许可选项)
  2. 有一个挂钩(客户端或服务器端),它将在进入存储库之前自动格式化代码
  3. 手动格式化代码。

关于第三点,概念是从不自动格式化代码并且有一些标准。现在,这似乎是我们所倾向的。我对这种方法有点犹豫,因为它可能会导致开发人员花费大量时间手动格式化代码。

如果任何人都可以请提供一些他们的想法和经验,这将是伟大的。

谢谢

马丁

+0

这就是我讨厌的WinForm设计器。您没有机会合并您与设计师联系的文件。 – 2010-04-14 20:59:38

回答

3

如果#1是不是一种可行的选择,#3可能是您的最佳选择。 #2会让个体开发人员在检查完工作副本和现有文件之间进行差异并在其上至少运行一次它们自己的格式化程序,这相当困难。选项#3主要是让人们进入习惯 - 如果每个人都可以进入相同的习惯,那么代码格式化并不是那么麻烦。您必须格式化的唯一代码是您创建/触摸的代码;其余的将从结帐格式化。

1

如果运行支持的格式格式的代码(有每晚构建,测试该代码每个夜晚),那么你可以有SVN签,可以强制执行该标准的一个pre-commit钩子脚本。

但是选项#3是最好的,因为在开发过程中更容易在IDE中设置格式规则。

9

不要让工具/开发人员仅出于美学原因自动/手动重新设置代码格式。修订之间的差异变成了一场噩梦。有一个编码标准,并尝试使用工具集,以获得新的模块尽可能符合您的要求。修改现有模块的人应该遵守该模块中使用的约定,无论他们是否喜欢。

+1

+10 upvotes如果我可以。摆脱代码格式化程序。能够看到/归咎于从一个转变到另一个转变的变化更重要。在编写看起来很丑陋的旧代码时,使用编码标准来处理未来的新代码,并学会“接受那些我们无法改变的东西”。 – 2010-04-07 19:55:23

0

我不知道这是一个技术问题还是一个文化问题。

即使他们都使用相同的工具,大多数工具允许您更改应用到文本的默认格式规则。

定义一些标准,通过同行评审和文化理解为什么它很重要。