風亂語
我想把這個問題轉化為兩個部分：第一個部分是怎麼判斷程序員的代碼好不好，第二部分想說說什麼樣的程序員，才是好的程序員。
好的代碼，就像是小說家手中的短篇小說，邏輯清晰，簡單明瞭，卻又能觸動心靈，而壞代碼，就像是一輛外表富麗的老舊汽車，開不動不說，隨時還有散架的危險。
究竟什麼樣的代碼才能算是好代碼？這是一個很有爭議的話題，每個人的理解可能都不一樣，所以制定一個符合自己部門要求的規範，有了依據，寫出來的代碼才有可能成為好代碼。
思考了一下題主提問題的場景，應該有兩種情況。一種是，就是自己本身不懂代碼，只是想知道怎麼判斷一個程序員的代碼質量另外一種情況，自己本身就是程序員，可能是剛學不久，不知道怎麼判斷好代碼的標準。
不懂代碼，如何判斷
如果你不懂代碼，那就直接判斷這個程序員是不是好程序員吧，判斷代碼，也不是你可以做的事。下面我會提到這一點。
好代碼的判斷標準
可讀性
好的代碼本身就是最好的說明文檔——Steve McConnell
代碼幾千行，所有業務邏輯全部揉在一起，除了你沒人看得懂，週末想續寫代碼，結果發現連自己也要看半天，才能接著寫下去，這樣的代碼，能是一個好代碼嗎？
判斷：將代碼拿給其他程序員看，在讀代碼期間，他向你提出的問題越少，說明這些代碼的可讀性也就越強。
要想讓部門所有人寫出的代碼可讀性強，就必須制定一個統一的開發風格，這樣不管是老程序員還是新程序員，都能快速上手，可讀性也會得到一定的保障。
可維護性
曾經看過一段代碼，一個method幾千行代碼，沒有人敢維護，修改一點點就會發生不可知的錯誤，代碼又臭又長，除了重構，完全沒有辦法。這樣的代碼，就是一個差到不行的代碼。
判斷：一般有三點可以做個大概的判斷，一是易讀，二是可拓展，三是數據靈活，四是可追蹤。
簡潔性
很多程序員之所以喜歡寫長代碼，主要是寫起來沒什麼障礙，也不用怎麼思考，跟記流水賬一樣。還有就是學習的時候，養成了一些不良的編程習慣，亦或是習慣成自然，已經不知道自己所寫的代碼，是不是夠簡潔了。
判斷：拿出以前寫過的代碼，讀一下，看看是不是簡潔了，如果是，至少說明你現在寫的代碼，比以前簡潔了。
模塊化
好的代碼，都是模塊化的。假設你的項目有三個不同的層，分別為內層、中層和外層。你的內容不應該從中層和外層那裡導入任何東西。中層不應該從外層導入任何東西，這樣做的好處是，你可以對代碼的內層進行獨立測試。
好程序員的判斷
出貨能力
寫一個程序，算法非常精妙，代碼質量也非常高，但產出效率非常低，也不能算是一個號程序員。之前我看過一個所謂的大神，算法很溜，但做事根本沒辦法按時完成進度，這也不行。
優化能力
沒有一個程序，是一步到位的，很多時候隨著業務的增大，對性能的要求越來越高，有一定的代碼優化能力也是非常重要的。
調錯能力
項目越大，遇到的bug會越力氣，這時候就需要強大的debug能力，找出最為關鍵的錯誤點，甚至追溯底層框架的源碼。
bug是不可避免的，但一個好的程序員，基本上不會因為代碼數量的增多，而導致bug也同步增多，如果原本bug是10佔1，後來代碼增多了，變為100佔3，而不是100佔10.
技術掌控
你的項目能用spring，hibernate等等框架，但是對於這些技術，你真的掌控了嗎？假如有一點，框架版本需要升級，你做得到嗎？或者從hibernate轉為mybatis？
剩下的，一些非技術相關的能力，比如學習能力、抗壓能力，這裡就不多說了。
——摘自W3Cschool學員的回答
W3Cschool
很多人不是天生就能寫一手好代碼，特別是剛開始工作一兩年的程序員。如果公司不注重代碼質量，只需要簡單寫下注釋，沒有代碼review的喜歡，那提高代碼質量全要靠自己了。
好的代碼一般簡潔，邏輯清晰，規範，設計模式運用得好。
一般公司會從你的代碼質量評估你的個人能力，推薦看下阿里巴巴java代碼規範，網上有相應文檔，還有相關書籍，比如《重構改善現有代碼設計》，《effective java》等書籍，對提升代碼質量很有幫助。
Java資深研發
程序員寫的代碼質量好壞可以從兩個角度入手
1.好的代碼一般通俗易懂
高手總會化繁為簡，寫的代碼首先是能讓人看懂，谷歌蘋果的工程師代碼提交之前都會找上週圍的同時給看一遍，如果對方覺得沒有什麼問題可以直接提交，並且在提交註釋裡面寫上reviewer名字，這樣同時也把責任給擔起來了，看似一個很簡單的模式，卻被絕大部分技術公司沿用。
所以代碼不能只有自己能看懂，讓別人能看懂你的思路，你的設計意圖。
2.好的代碼，遵守整個系統編碼規範，不出格，最重要的一點好的代碼能夠經得起實踐的考驗，在實際運轉過程中，沒有很重大的系統崩潰出現才能稱得上好代碼
所以代碼不能只是看著好，在性能上也需要有不俗的體現，對於程序員來講代碼就是臉面，特別是在團隊配合之中，如果一個人寫的代碼質量高就會給人形成一種靠譜的感覺，在配合過程中也比較容易形成默契的感覺，一看誰寫的代碼如果平時代碼質量高，大家在調用該模塊的時候會覺得很舒心，很放心。代碼直接關係著程序員的品質問題了，有很多老程序員對於代碼質量非常關注，不允許自己犯一些很低級的錯誤，導致自己的名譽受損。
大學生編程指南
作為一名從事互聯網行業多年的老程序員，我來回答一下這個問題。
在我看來程序員代碼的好壞標準也與計算機行業的發展有密切的關係，早期的程序員非常注重代碼的執行效率，比如時間複雜度和空間複雜度等，當前的程序員對代碼的可讀性和規範性也非常重視，因為目前的軟件開發都是團隊行為，團隊合作一定要有規範性的代碼要求。
我目前對團隊程序員的代碼要求主要集中在以下幾點：
第一，代碼的規範性。所謂代碼的規範性指的就是代碼的模塊清晰、可讀性強、格式良好、命名合理、註解詳細。代碼的好壞第一眼是模塊劃分是否清晰，然後是格式，再然後是邏輯是否清晰。如果這段代碼執行的結果是正確的，但是邏輯混亂，這樣的代碼就不是好的代碼，這也是很多初級程序員經常犯的錯誤，如果不及時指正，對他未來的發展會非常不利。
第二，代碼的執行效率。代碼的執行效率往往體現了一名程序員的能力，不同的代碼在執行效率上差距非常大。代碼的執行效率涉及到時間複雜度、空間複雜度，對算法的選擇和實現思路決定了程序的執行效率。有經驗的老程序員往往在執行效率上有多套完整的解決方案，這是年輕程序員需要重點學習和提高的地方。
第三，代碼的擴展性。代碼的擴展性主要體現在代碼結構的設計上，運用規範的模式能夠在很大程度上保證代碼的擴展性。程序沒有不修改的，修改就涉及到功能的擴展，而好的代碼在功能擴展上就比較方便。比如在完成一個簡單的數據存取功能的時候，程序員會按照實體類、接口、實現類、工廠類的結構來設計，這樣以後的擴展會非常簡單。
最後，不同的開發團隊往往有不同的規範要求，程序員一定要仔細學習並掌握，這對以後的團隊合作非常重要。作為軟件團隊的一份子，一定要記住不要犯低級錯誤！
我帶軟件團隊多年，我會陸續在頭條上分享一些開發方面的科普文章，感興趣的朋友可以關注我的頭條號，相信一定會有所收穫。
如果有開發方面的問題，或者是考研方面的問題，都可以諮詢我。
謝謝！
IT人劉俊明
1.代碼佈局工整，這個應該都能做到。
2.模塊化寫代碼，把一個個功能進行模塊化，方便找bug和修復。
3.邏輯思維，邏輯好的可能幾句代碼就解決一個功能，但邏輯不好的可能需要幾十行或更多的代碼來實現，這個得多練。
4.底層知識掌握程度，這個會影響程序的崩潰，出錯，卡頓，計算速度。底層知識過硬可以很好的避免。
5.多練可以提高效率和降低bug，如果是一個新手，一句代碼幾個十幾個bug都很正常
梵蒂岡偷渡來的難民
一個程序寫的好不好，需要多方面考慮。
可讀性。一個讓別人看的非常費勁的代碼不是好代碼。也許自己過段時間也會看不懂。
健壯性。bug滿天飛的代碼，肯定不好。比如 "".equals(obj)絕對比obj.equals("")好。
擴展性。程序中不要有死代碼。
關注我，每天兩篇編程知識！
