近幾天，算是掉進來一個巨大的焦油坑，我和另外三個同事備受折磨。現在三個有一個跑去裝機器了，暫時不寫代碼，還有我和另外一個同事。
其實代碼復雜度不是很復雜，但是代碼審查（簡稱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經濟又實惠？
先謝謝大家