关于团队开发时，代码格式化的问题

多个人同时对某个文件进行开发
但是可能他们格子的代码格式化风格都不同
这样通过CVS merge的时候可能只是因为格式问题而导致对比差异过多

一种假设，没法没有办法强求所有人使用同样的格式化风格
（其实我认为这个反而是最容易实现的解决办法）
另外一种假设，对于公用维护的代码，只允许对自己维护的片断进行代码格式化

大家怎么解决这个问题的啊？
BTW:
我的老大对代码格式化非常的不赞同
说这是team work的大忌...

ant checkstyle task

强制所有人使用同一种style？
那还不如强制所有人使用同一种eclispe的style format格式文件呢。反正是可导入导出的

一个团队里面保持相同的风格是非常必要的。
eclise是可以进行块代码格式化的，先选中即可。

这需要自动化的。checktyle可以自动化。
如果靠人自己按ctrl+alt+f，有时候会忘记。
而checkstyle不光是检查format
还可以对一些java的编程习惯作提示，例如final static，变量习惯等
这对于一个team来说是必须的。
你需要先建立一个持续集成环境。如果有人break builds就发出提示

没错，搂住要听nimo的劝告，这可以人家血的教训积攒的经验。

能否请你代言一下是什么样的血泪教训？我现在对这个问题恰好较感兴趣，希望能与你好好讨论一下。

根据我的观察和感觉，大部分公司实施代码检查通常是一种管理行为，即促进团队形成的一种手段，通过强制统一的风格（类似军队、学生统一着装），潜移默化地促进团队的形成。
如果指望靠代码检查来增进代码的可理解性，这里有我的一点总结。造成代码难以理解的原因，按照重要性如下递减：

1. 没有能反映真实情况的需求、用例、设计文档
2. 虽然有文档，但是设计太糟糕，造成代码结构混乱不堪。
3. 代码组织太差，比如出现行数过百的大函数，或者强行把不相关的代码写在一个类中。
4. 缺少必要的注释。
5. 变量名称错误，不能反映变量所代表的含义。
6. 变量名称不符合规范。
7. 代码缩进等细小的风格问题。

这几个问题，只有6和7能通过代码检查解决，但是6和7实在是不怎么重要。

我唯一观察到的有真实价值的代码风格检查出现在这种场景中：客户在合同中即要求开发方提供全部最终源代码。此时的源代码上可能需要加入公司的统一标识、版本、作者等一些版权信息，同时整齐的代码会显得更“专业”一些。

请Swing兄发表一下看法，在你的印象中代码检查在哪些真实的场景中发生了很大的作用？

1、定下命名规范，以统一思想为指导

2、分发：JavaCodeStyleEclipse.xml

3、ANT　CheckStyle

4、CVS Commit

以工具协助执行

第 3 點其實也是可以的，只要團隊肯嚴格配合 (如，限制函式/程式行數...)

程式撿查不能代替編程的技巧，重點還是編程者的素質，但自動且適當的撿查可一定程度定出個程式品質的下限。

還有，我不覺得代碼縮進"等"是個"細小的風格問題"，這對編程的順暢和程式的品質有相當大的影響，程式排版也不只是代碼縮進而己，做得好可以避免很多不必要的小錯誤。

我也认为如此，就像你说的，重点还是编程者的素质，代码检查能起到的作用太小。
所以我才希望有人能举出真实的例子，究竟在什么情况下，不使用代码检查会造成严重的问题。