不知從什麼時候開始，我經常會思考一個問題，即什麼纔算是一個好的代碼？我們來看看這一段描述：
‘Good code’ is code that works, is bug free, and is readable and maintainable. Some organizations have coding ‘standards’ that all developers are supposed to adhere to, but everyone has different ideas about what’s best, or what is too many or too few rules. There are also various theories and metrics, such as McCabe Complexity metrics. It should be kept in mind that excessive use of standards and rules can stifle productivity and creativity. ‘Peer reviews’, ‘buddy checks’ code analysis tools, etc. can be used to check for problems and enforce standards.
好的代碼是代碼運行正常、bug很少、並且具有可讀性和可維護性。一些企業自己有所有開發人員都必需遵守的編碼規範，但是對於什麼樣的代碼是最好的每個人的都有自己的標準、或者有太多的或太少的編碼規則。這有多種原則和標準，例如，McCable 的複雜度度量。的確使用過多的編碼標準和規則可能降低生產率和創造性。“同行評審”或“同事檢查”代碼分析工具等，都能用來檢查問題或堅持標準。
是的，這一段話算是回答了我的疑問，但在我看來這還是片面的。對於這個問題我的看法就是：解決了實際問題的代碼算是好代碼。不論是redis，nginx都是這方面的標杆，它們都是作者對現況不滿而被創造出來用以解決實際問題的，而且確實解決了問題。不是說這兩個項目在難度上有多大，找一個有意願的大學生，在肯鑽研的情況下，我相信他一定能看懂那兩個神作的代碼。在這個方面來說，我認爲libco是一個好項目，因爲它確實完美的承接了微信後臺從半同步半異步到異步的轉化，並且代碼的實現也可圈可點，很多地方的精巧設計確實不是常人所能完成的。
但是我覺得從一個開源項目的角度來說libco不能算是一個好的項目。因爲它的官方文檔幾乎可以理解爲0，也就是啥都沒有。我甚至懷疑在libco被開源的前一天晚上TX的工程師們在一行一行的刪註釋。可能整個libco的註釋加起來也沒有一百行吧。其次其實libco的社區至少在github上來說並不是特別活躍，提了幾個issue，交了幾個patch，issue的回覆是答非所問，patch這麼久過去了也沒有收到回覆。可以看到最早的更新也在半年以前。
當然這些都是可以理解的，畢竟幹這事可能公司也不會多發工資。
參考：
- 博文《究竟怎樣寫代碼纔算是好代碼》