首先我們相信寫好代碼是非常重要的。為什麼呢？首先，好代碼比差代碼更有趣，成本更低。其次，代碼好，就意味着你正在建構的産品有可能會更好。第三，也是非常關鍵的一點，寫出好的代碼是我們的職責：畢竟，我們的工作就是寫代碼。
good code measure is wtf/minute by osnews
方法
由于此65名開發人員都是我們某個職位的應聘者，是以這意味着這些樣品開發人員大多偏向于使用java或scala技能，并且通常有着5年及以上的工作經驗。
問題統一：“怎樣寫好代碼？你如何定義好代碼？”并且在面試時由同一人（面對面或通過電話），曆時約1年，從2014年1月至2015年1月，來執行此地調查。
梳理這些問題的答案之後，可以分為31個不同的類，每組至少有2個相似的答案。例如，下面這些答案通通歸納為可讀一類：
可讀。
人腦可閱讀。
能自我解釋。
人們能讀懂。
很容易了解。
不用5分鐘就能了解。
沒有文檔，你也可以閱讀并了解。
可讀，新來的開發人員也能夠了解。
就如同文本一樣可讀。
易于閱讀，直線化的思維。
結果
這65位開發人員的答案總共統計出288條不同的内容，平均一個人4.43條。
當然，目前最常見的答案是，代碼必須可讀（78.46％），幾乎10分之8的開發人員認為，好的代碼應該易于閱讀和了解。
然後是可測試的/測試過的（29.23％），這說明好的代碼應當是經過自動化測試的（或至少是有可能執行測試的）。25%的受訪者認為，良好的代碼
還應該是簡單的——不過于複雜，當然還應該是可以工作的，意味其能夠按照我們的意願正常執行功能。前五條是，代碼應該是可維護的（21.54％）。
奇怪的是，我們發現有兩項内容是關于同一主題的：文檔和代碼注釋。有的開發人員認為代碼應該自文檔化（不需要用文檔解釋），而有些開發人員則表示應該在代碼中着重于注解，說明代碼目的。
其他的，如，可擴充的/可重複使用的，恰當的命名規律，代碼解耦或者稱為小方法的重要性——當然這個“小”在不同開發人員的眼中概念還不一樣：“10-15行”到“<50行”莫衷一是。
characteristics of good code
探讨
面試中的回答給了我們很多有趣的可用于分析的定量資料，而有些資料非常值得一提。下面這些是我們點贊量最多的答案，有的讓我們會心一笑，有的有理有據值得深思：
再怎麼測試也不會發生崩潰。
不要建立那些并不需要的玩意兒。
任何人都需要寫點注釋。好不好以後自然會知道。
你看到它，它才有意義。
你需要了解業務目的。
你需要做的不僅僅是寫代碼。
不需要太過于特立獨行。
差的代碼也能做很多事情，但就是通通做不好。
開發人員重視代碼的可讀性和可了解性并不奇怪。但是令人有一點點驚訝的是，其餘的回答卻差不多至少有50％的差異！
how to write good code by xkcd
以下這四條就屬于讓人驚訝的後者：
可維護：因為我們大多數人都有過維護别人代碼的經曆（或者一段時間以後維護自己的代碼），并且很有可能度過了一段非常悲慘的日子。是以，我們期待更多的開發人員能夠編寫出可維護的代碼。可能有的人假設代碼可讀，那麼一定易于維護，是以就忽略了這一條。
可工作：編寫代碼的目的，就是能夠為他人提供價值。編寫可工作的代碼，是我們的首要任務之一。是以我們很驚訝為什麼并不是每一個開發人員的答案中都囊括這一條。
可測試/已測試過的：測試的重要性在這裡我就不多說了，相信大家已經聽到過不知道幾百遍了。
高效：話說，答案中包含“高效”的開發人員比強調“不可過早優化”的開發人員，要多兩倍，而衆所周知，“過早的優化是萬惡之源”，是以，這太讓人納悶了。
最後，我們總結出好代碼的定義：
“好的代碼是可讀的，可了解的，覆寫了自動化測試的，不過于複雜，并且能辦好我們需要它做的事情。”
聽起來就相當美，right？
來源：51cto