强制执行编码风格

25

多年前,当我开始进行一个小型开发项目时,其他的开发人员和我坐下来商量达成了一种折衷的括号和缩进风格。虽然不是任何人最喜欢的,但也不是任何人真正讨厌的。我编写了一个.indentrc配置文件,以该样式为基准,并有一个检入触发器,可以在每次检入文件时运行indent命令。这样无论你用哪种样式编写代码,都会在别人看到之前成为团队标准,从而保证了代码风格上的一致性。但我从未见过其他人在此之前或之后采用这种方式。

那么,你们其他人怎么看呢?这是个好主意,还是灾难?


1
+1:好主意 - 下面列出的一些增强功能也可能是积极的补充。 - Ken Gentle
1
现代IDE使这种宗教性的事情变得无关紧要。只需两个按键,文件就可以呈现开发者想要的样子。谁在乎它在源代码控制中的样子。当然,这也使得查找编辑变得很麻烦。 - Robert C. Barth
2
@RobertC.Barth:为什么不直接使用rsync作为你的版本控制系统呢?它拥有所有好的功能:分散式、ssh、压缩。谁需要diff,blame和三路合并啊? - Sebastian Mach
8个回答

16

我认为这是个好主意。我觉得可以更进一步,让每个人在他们的IDE中使用配置文件,以便默认使用协商一致的编写风格。如果他们将要查看其他人的代码,则最好适应中性样式。即使是他们自己的代码,在一次提交和检出周期后也应该采用中性样式,那么为什么要用自己的个人风格开发新代码呢?


14
采用中立的编码风格绝对是个好主意。然而,只有在检查源代码时强制执行编码风格可能是一个好主意,也可能不是一个好主意(见下面BillElie的答案)。
使用检入挂钩:
优点:允许程序员按照自己的方式编写代码,因此他们不必考虑标准或更改编写代码的方式。这最大限度地减少了对政策的抵抗,并且在编写代码时不会对其生产力产生负面影响。
缺点:您的程序员可能只对中立样式略知一二,因此您没有得到每个人都使用“相同”样式的全部好处。如果您的程序员必须在配对编程设置中共同工作,他们仍将受到彼此在屏幕上显示的编程风格的影响,这将与他们自己的风格或中立风格不同。
更进一步,使用中立风格进行开发:
优点:鼓励流利使用中立风格,每个人在检入前后都可以阅读其他人的代码。
缺点:以这种方式做,您将遇到更多的开发人员的抵抗。根据您的文化背景,它可能带来的麻烦超过了它的价值。

9

如果你只限制于强制约束花括号和缩进的样式,那么我认为这是个好主意。然而,如果你试图强制执行每一个格式标准,那么可能不太可行。在我看来,有时打破标准是有道理的。例如,我更喜欢

int x = y * z;

to

int x = y*z;

因为更易于阅读。然而,我非常喜欢

int a = b*c + d*e;

to

int a = b * c + d * e;

因为空格表示操作顺序,所以您执行强制缩进和括号的策略听起来非常不错。但是,如果有人试图盲目执行其他空格规则,我认为效果将不佳。

2
只要每个人都同意一个可接受的标准,我认为为什么不能将其包括在大括号样式和缩进中。 - Bill the Lizard
6
我喜欢OpenBSD在这方面的理念。如果为了符合一般标准而牺牲易读性,那就不要这样做。易读性才是标准能够真正制定的原因。然而,这应该是例外而不是常规。 - Kenny Mann
@Nazadus - 我喜欢那个见解。 - Draemon

4

听起来是个不错的主意。只要最终的样式不是完全陌生的东西,那么这是确保开发人员使用该样式的好方法。而且它还有一个额外的好处,就是他们不必以这种方式编码 - 当他们提交更改时,它将被重新格式化。如果您能够将这样的工具插入到您的CVS(通用术语)中,那将是很不错的。


CVS(通用术语)-> VCS/SCM? - hangy
代码版本控制系统,但不是任何特定的系统。 - Elie

3
使用自动代码格式化工具的最大问题是当代码格式化程序无法处理每种情况时。
例如,如果您的代码中有很多SQL语句,您可能会自动格式化SQL。但是,如果您的SQL超过一行(一行有多长呢?),那么您必须手动格式化它。到目前为止,我还没有看到一个能够正确处理这个问题的好的格式化程序。
示例:
String sql = "SELECT * FROM USERS WHERE ID = ? AND NAME = ? AND IS_DELETED = 'N'";

vs

String sql = 
  "SELECT * " +
  "FROM USERS " + 
  "WHERE ID = ? " + 
  "  AND NAME = ? " +
  "  AND IS_DELETED = 'N'";

第二种格式在查询非常长的情况下更易读。大多数格式化程序会将其解析为一行长达行长度的长行。 但是,如果你只是简单地转换...
if(x=1) print("blah"); else print("eep!");

转化为

if (x = 1) {
  print("blah");
} else {
  print("eep!");
}

那么格式化程序就可以了。我们在工作中也做类似的事情;这不是由CVS工具强制执行的,而是由IDE强制执行的。效果还算不错。


1
你的 IDE 还应该警告在条件语句中使用 = 符号。例如,开启警告的 GCC 会要求你写成 "if ((x = 1))",以表明你的意图实际上是使用 = 而不是 ==。 :-) - C. K. Young
嗯,也许它不是C或Java代码,而是一些使用“=”作为比较运算符的其他语言 :) - Mr. Shiny and New 安宇
+1,然而,应该将代码嵌入字符串文字中视为例外而非规则的一部分。 :) - Sebastian Mach
@phresnel:在许多环境中,没有很好的处理SQL的本地方法;它只能被嵌入到字符串文字中。虽然这很烦人。 - Mr. Shiny and New 安宇

2
我们使用带有一组Stylecop规则的签入策略的TFS。如果您的代码未通过审核,您无法签入。这种方法非常有效。除了保持一致的风格和良好的注释外,它似乎还提高了代码的质量——可能是因为开发人员被迫描述每个方法、事件等,他们在签入之前不得不更多地考虑代码。
虽然这只是一个微软解决方案,但如果您可以使用它,那么它是值得的。

当然,使用Java技术也可以做到这一点,我相信在C/C++中有可用的开源工具可以执行相同的操作。不确定新的脚本/动态语言是否能够做到。 - Ken Gentle
一些工具,如checkstyle,允许您在Java中执行类似的操作。 - Mario Ortegón

2
有一个名为EditorConfig的项目可以在一定程度上解决这个问题。然而,它目前只能解决缩进问题。
EditorConfig 包含适用于许多不同编辑器的插件和文件格式标准。通过在项目根目录下创建 .editorconfig 文件并安装相应的插件,编辑器将在您输入代码时对其进行格式化。
这是一种通用的方式(与 indentrc 不同,不限于 C/C++),但您仍然可以查看这种解决方案。

我已经更新了CodePainter项目,现在它可以与EditorConfig紧密配合,这样你就可以在JavaScript方面获得最佳效果了,至少是这样的:https://github.com/jedhunsaker/codepainter - jedmao

0

我相信你现在已经决定了你的开发环境。如果你使用Eclipse,你可以在Java编辑器上启用格式化源保存操作,这样每次保存时都会重新格式化。这样做的主要好处是,在源代码库中标记源代码更改的时间是在实际更改时,而不是后来重新格式化时。

将其变成自动步骤。以后你会感激不已。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接