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

不过我这样说,并不是赞成楼上说merge只是美丽童话. 代码格式化对于自动化merge有一定帮助,但从来不代表代码格式化是给Merge使用的.所以楼主将这两个话题放在一起讨论,有些牵强.

多谢前面的讨论。
我的问题的确是从merge出发的，没想到引发到代码格式标准的应用讨论上去了
单就merge这点而言，代码标准也只能为这个神话做一层简陋的铺垫而已
cvs merge，依然有不少容易出错的地方

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

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

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

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

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

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

2. 虽然有文档，但是设计太糟糕，造成代码结构混乱不堪。

3. 代码组织太差，比如出现行数过百的大函数，或者强行把不相关的代码写在一个类中。

4. 缺少必要的注释。