近几天，算是掉进来一个巨大的焦油坑，我和另外三个同事备受折磨。现在三个有一个跑去装机器了，暂时不写代码，还有我和另外一个同事。
其实代码复杂度不是很复杂，但是代码审查（简称CR）就是过不了，来来回回的改，若是去和较真CRer，貌似也理由也不是很充分，添加的CR评论多半是“我觉得”，“我认为”，CR代码的spell check和style check胜过代码的逻辑check。
比如，你一个循环，可能多半人都会这么写：
for(int i=0;i<100;i++){ ......} |
但是可能有些人会这么写
// The max number is 100 int maxNum=100; // Add some comments here for(int num=0;i<maxNum;i++) { ....... }
当然第二种方式看起来比第一种“优雅”，但是我认为第一种也不为过。
现在没人关心这段代码能不能得到想要的结果，这个只能写code的人去心中有数了。
可能有人会提到易读性，维护性，我想这个有时候有点小题大做了，代码足够简的情况下，如果还要掰扯个最优写法，吹毛求疵，不为过。
如果写每一段代码都要考虑，这个是不是别人看会不会明白？会不会造成误解？是不是已经足够清晰？
那这个就不是写代码，这个就是写文章了。
我认为代码的易读性跟怎么写不太有关系，而是跟你整个框架的搭建，对行为的抽象精炼有关系。
再举个例子：http://msdn.microsoft.com/en-us/library/ms243496(v=vs.110).aspx
相信大家在写单元测试的时候广泛用到Assert，有这么一个方法。
public static void AreEqual( Object expected, Object actual, string message )
关于第三个message参数，msdn是这么定义的：
messageType: System.String A message to display if the assertion fails. This message can be seen in the unit test results.
说白了就是写一个信息，然后在断言失败的时候打印出来。
但是注意，这虽然是一个message of error，但是msdn 没有将message定义为errormessage，errormsg等。也就是说没有给这个message定性，只是说在失败的时候打印一个message。
其实你要是说写一个Assert.AreEqual("Bob", userName, message) 你会怎么写你的message。
如果失败，他会打印出：
Expected : "Bob"; Actual :"Boa", message
先说我的想法，我是在message写明这个断言的作用，会写“Verify if the user name is 'Bob' or not”, 表明这个断言在验证什么。
但是按照我们现在的写法，他需要写成“ Verify user name ‘Bob’ fails.”， 区别在于我的是个不确定的语气，而规定是肯定句。
其实有必要掰扯message怎么写吗？按照多数人来说，可能觉得微不足道。
我其实两者怎么·写都可以接受，但是就因为我的这种写法，被谈话许久，其实最后的的结论就是看到第二种写法，第三者不用看code就知道哪里的功能错了。
这个理由仍然不能让我信服，既然你能看到message，说明断言已经失败了，继而看到这个断言在验证什么也可以推知错误所在。
最后我把messge给删除了，就光verify，不显示message，也不错吧。
但是人在屋檐下，怎么着我都是能接受的，你让我怎么写我就怎么写，你制定出个rule出来，我follow就好了，不是吗？
这就好比我不懂OO，我反OO难道我就不能写出好的code吗？不见得（我且认为满口OO的人，才是最不懂OO的人）
=================================================================================
代码如文章，现在几个人写一本书也不可能都文风一致。
现在每天最头疼的，不是功能如何事先，而是纠结
如何给一个变量起个名字，现在是能不用变量就不用变量，函数里套函数
如何添加注释，现在是能不写就不写，写了 反倒多余
代码空格对齐问题 哪里少了1个空格，哪里哪里要对齐。。。。。。
新function能不写就不写，堆代码，写了有人会comment
蛋疼的事情一大堆
。。。。。。。。。。。。。。。。。。。。。。。。。。。
新的代码怎么放置，添加一个文件如何命名，一个变量放在哪个文件里都需要请示。
====================================================================================
关于代码风格，我认为只要不是堆砌，只要风格简洁，思维通顺，就为好的。而且你既然作为一个程序人员，基本的阅读别人代码的能力是必须的。
好的代码能让人明白你的思维，你能明白你当时的设计思路。
跟一同事飞总说了两句，说了句经典的：他们看不懂逻辑，所以就只能挑code style和format的错。
啰嗦完毕，吃饭
也请大家谈谈自己的意见，该怎么做CR经济又实惠？
先谢谢大家