执行编码风格

多年前,当我开始一个小型开发项目时,其他开发人员和我坐下来同意妥协支撑和压痕样式.这不是任何人的最爱,但这是没有人真正讨厌的事情.我为该样式编写了一个.indentrc配置文件,并且有一个签入触发器,它会在签入时对每个文件运行缩进.这使得它与你编写代码的样式无关,在任何人看到它之前,它最终会成为集团的标准.这具有一致性的优点.但我从来没有见过其他人这样做过.

那么你们其他人怎么说呢？好主意还是可憎的？

1> Bill the Liz..：

---

我会说好主意.我会更进一步,让每个人在他们的IDE中使用配置文件,以便他们默认使用约定的样式编写.如果他们不得不以中性风格看待其他人的代码,他们也可能会习惯它.在一个签到签出周期后,即使他们自己的代码也应该处于中性风格,那么为什么要以自己的个人风格开发新代码呢？

2> Adam Bellair..：

---

采用中性编码风格绝对是个好主意.但是,只有在签入来源时强制执行编码风格可能会或可能不是一个好主意(另请参阅下面的Bill和Elie的答案).

使用签到挂钩:

Pro:允许编码人员按照自己的意愿编写,因此他们不必考虑标准或改变编写代码的方式.这可以最大限度地减少对策略的抵制,并且在编写代码时不会对其生产力产生负面影响.

Con:你的程序员可能只是熟悉中性风格,所以你没有得到每个人使用"相同"风格的全部好处.如果你的程序员必须在一对编程设置中一起工作,他们仍然会在屏幕上受到彼此的编程风格,这将与他们自己的风格或中性风格不同.

更进一步,在开发过程中使用中性风格:

专业:鼓励流畅的中性风格,每个人都可以在签到之前和之后阅读其他人的代码.

Con:你会遇到更多来自开发人员的阻力.根据您的文化,它可能比它的价值更麻烦.

3> Eli Courtwri..：

---

如果你将它限制为在括号和缩进上强制执行样式,那么我认为这是一个好主意.但是,如果您尝试强制执行每个格式标准,那么它可能不会.在我看来,有时候打破标准是有道理的.例如,我更喜欢

int x = y * z;

至

int x = y*z;

因为它更容易阅读.但是,我非常喜欢

int a = b*c + d*e;

至

int a = b * c + d * e;

因为间距代表操作的顺序.

因此,您执行缩进和括号的政策听起来非常好.但如果有人试图盲目执行其他间距规则,我认为它不会很好.

---

我喜欢OpenBSD的想法.如果你不得不牺牲可读性来保持一般标准,那么就不要这样做.可读性是标准真正制定的原因.但是,这应该是例外 - 不是常态.

---

只要每个人都同意一个可接受的标准,我就不明白为什么不能包含它以及支撑样式和缩进.