風亂語
0x01 先看註釋
這一點很重要，放在第一點來說。很大程度上註釋反映了一個程序員的編碼思路，你可以從註釋中看到一個程序員對業務的理解程度，甚至編碼的態度。好的註釋可以讓你輕鬆的閱讀代碼，不費吹灰之力快速瞭解一段代碼的核心思路，彷彿一切都是水到渠成，對這種代碼的修改或者擴展也是如沐春風。但是如果一段代碼註釋混亂或者根本就沒有註釋，那麼後期維護難度可想而知，即使原作者過個把月再回來看這段代碼也會罵一句，屎一樣。
0x02 代碼整齊度
這個很好理解，舉個栗子，見下圖
這種代碼讓人提不起閱讀的慾望，寫這種代碼的程序員是不是一個好的程序員大家自己判斷。
再看看下面這段
歡迎大家關注 嵌入式瘋狗 狗哥等你來一起玩耍哈
嵌入式瘋狗
寫了十多年代碼，見過很多爛代碼，也見過不少優秀的代碼，那麼如何判斷代碼的好與壞呢，我談談自己的看法。
好的代碼，就算外行看到也會說是好代碼
首先，好的代碼會嚴格遵守代碼規範。從代碼的格式、命名、註釋，就能看出來代碼的好壞：遵守代碼規範的代碼不一定好代碼，但好代碼一定會遵守代碼規範。
所以我經常說，好的代碼，讓一個外行人看，就算他看不懂寫的什麼，但是他也會說寫的不錯。
實現需求，並考慮可擴展性
代碼必須要實現需求，這是及格線，對於好的代碼，評定標準會更高。
舉個簡單的例子：
客戶提了一個需求，查詢展示客戶列表，對於賬戶餘額超過10萬的客戶，標紅展示。
代碼也很容易，餘額>=10萬{特殊處理}。
過幾天，需求說，10萬這個標準有些低了，變成50萬吧。
然後改代碼，餘額>=10萬{特殊處理}，然後上線。
又過了幾天，需求說，50萬有些高了，調整成30萬吧...
如果把這個限額標準做成可配置的，是不是就靈活很多。（你要是把配置放在數據庫中，每次判斷去查詢的話，你還是寫死在程序裡面吧）
我們圈子裡就有一個傳言：一個優秀程序員的品質，就是可以準確的蒙對客戶要變化的需求。
注重業務功能，也要注重代碼效率
工作十多年，我遇到很多這樣的程序員：一心一意實現業務邏輯，在測試環境跑的沒有問題，一上生產就卡死。因為測試環境有一千條數據，生產環境有一千萬條數據。
所以好的代碼，會根據實際生產環境的實際情況，進行一定程度的設計和優化。（優化是無止境的，適度就好）
我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。
會點代碼的大叔
理論上講，好的代碼要簡潔，邏輯清晰，易擴展，良好的封裝等等。
但在實際中，吐槽代碼已成了程序員的日常。
借用亞馬遜工程師的話，來形容說他們的代碼:“一座很大的屎山，你見過的最大的山，每次你想修正一個bug，你的工作就是爬到屎山的正中心去”。
我們組曾有一個著名的6000行後端JS，沒有面向對象封裝，純靠函數。 其中有好幾個上千行的函數，帶了二十多個形參，幾個標誌位，分別有十幾個數字狀態。註釋？沒有的。
每一個接手過這段代碼的人都會不約而同的發一條朋友圈以示佩服。
但神奇的是，代碼在執行上基本沒太多的錯。
直到幾個月前，一個大牛在走之前把這段代碼全部重寫了一遍，留下了至今都沒有改完的bug。
非著名程序猿
Java程序員中非常流行阿里巴巴Java編碼規範，這是阿里對Java程序員的規範要求，一公佈引起很大反響，筆者作為把阿里規範看了不下五遍的人，不得不承認如果代碼能按照編碼規範來寫，那將是非常優秀的。不僅僅是影響了代碼的整潔度，有些規範的編寫將非常有利於軟件的性能和穩定性。
判斷代碼好壞我有以下幾個方法:
- 首先先看代碼的規範性，比如駝峰寫法，比如是否在每個接口處都帶有註釋。這些可以用阿里插件掃描。
- 其次，可以用sonar等工具進行掃描，看看代碼是否有空指針的可能性，還有些“壞味道”的代碼。
- 最後，可以看看這些代碼的細節，具體實現方式，在核心算法裡有沒有註釋，是否冗餘，是否會有更好的寫法替代。
關注“極客宇文氏”更多幹貨經驗分享。極客宇文氏
作為一名從事互聯網行業多年的老程序員，我來回答一下這個問題。
在我看來程序員代碼的好壞標準也與計算機行業的發展有密切的關係，早期的程序員非常注重代碼的執行效率，比如時間複雜度和空間複雜度等，當前的程序員對代碼的可讀性和規範性也非常重視，因為目前的軟件開發都是團隊行為，團隊合作一定要有規範性的代碼要求。
我目前對團隊程序員的代碼要求主要集中在以下幾點：
第一，代碼的規範性。所謂代碼的規範性指的就是代碼的模塊清晰、可讀性強、格式良好、命名合理、註解詳細。代碼的好壞第一眼是模塊劃分是否清晰，然後是格式，再然後是邏輯是否清晰。如果這段代碼執行的結果是正確的，但是邏輯混亂，這樣的代碼就不是好的代碼，這也是很多初級程序員經常犯的錯誤，如果不及時指正，對他未來的發展會非常不利。
第二，代碼的執行效率。代碼的執行效率往往體現了一名程序員的能力，不同的代碼在執行效率上差距非常大。代碼的執行效率涉及到時間複雜度、空間複雜度，對算法的選擇和實現思路決定了程序的執行效率。有經驗的老程序員往往在執行效率上有多套完整的解決方案，這是年輕程序員需要重點學習和提高的地方。
第三，代碼的擴展性。代碼的擴展性主要體現在代碼結構的設計上，運用規範的模式能夠在很大程度上保證代碼的擴展性。程序沒有不修改的，修改就涉及到功能的擴展，而好的代碼在功能擴展上就比較方便。比如在完成一個簡單的數據存取功能的時候，程序員會按照實體類、接口、實現類、工廠類的結構來設計，這樣以後的擴展會非常簡單。
最後，不同的開發團隊往往有不同的規範要求，程序員一定要仔細學習並掌握，這對以後的團隊合作非常重要。作為軟件團隊的一份子，一定要記住不要犯低級錯誤！
我帶軟件團隊多年，我會陸續在頭條上分享一些開發方面的科普文章，感興趣的朋友可以關注我的頭條號，相信一定會有所收穫。
如果有開發方面的問題，或者是考研方面的問題，都可以諮詢我。
謝謝！
IT人劉俊明
我想把這個問題轉化為兩個部分：第一個部分是怎麼判斷程序員的代碼好不好，第二部分想說說什麼樣的程序員，才是好的程序員。
好的代碼，就像是小說家手中的短篇小說，邏輯清晰，簡單明瞭，卻又能觸動心靈，而壞代碼，就像是一輛外表富麗的老舊汽車，開不動不說，隨時還有散架的危險。
究竟什麼樣的代碼才能算是好代碼？這是一個很有爭議的話題，每個人的理解可能都不一樣，所以制定一個符合自己部門要求的規範，有了依據，寫出來的代碼才有可能成為好代碼。
思考了一下題主提問題的場景，應該有兩種情況。一種是，就是自己本身不懂代碼，只是想知道怎麼判斷一個程序員的代碼質量另外一種情況，自己本身就是程序員，可能是剛學不久，不知道怎麼判斷好代碼的標準。
不懂代碼，如何判斷
如果你不懂代碼，那就直接判斷這個程序員是不是好程序員吧，判斷代碼，也不是你可以做的事。下面我會提到這一點。
好代碼的判斷標準
可讀性
好的代碼本身就是最好的說明文檔——Steve McConnell
代碼幾千行，所有業務邏輯全部揉在一起，除了你沒人看得懂，週末想續寫代碼，結果發現連自己也要看半天，才能接著寫下去，這樣的代碼，能是一個好代碼嗎？
判斷：將代碼拿給其他程序員看，在讀代碼期間，他向你提出的問題越少，說明這些代碼的可讀性也就越強。
要想讓部門所有人寫出的代碼可讀性強，就必須制定一個統一的開發風格，這樣不管是老程序員還是新程序員，都能快速上手，可讀性也會得到一定的保障。
可維護性
曾經看過一段代碼，一個method幾千行代碼，沒有人敢維護，修改一點點就會發生不可知的錯誤，代碼又臭又長，除了重構，完全沒有辦法。這樣的代碼，就是一個差到不行的代碼。
判斷：一般有三點可以做個大概的判斷，一是易讀，二是可拓展，三是數據靈活，四是可追蹤。
簡潔性
很多程序員之所以喜歡寫長代碼，主要是寫起來沒什麼障礙，也不用怎麼思考，跟記流水賬一樣。還有就是學習的時候，養成了一些不良的編程習慣，亦或是習慣成自然，已經不知道自己所寫的代碼，是不是夠簡潔了。
判斷：拿出以前寫過的代碼，讀一下，看看是不是簡潔了，如果是，至少說明你現在寫的代碼，比以前簡潔了。
模塊化
好的代碼，都是模塊化的。假設你的項目有三個不同的層，分別為內層、中層和外層。你的內容不應該從中層和外層那裡導入任何東西。中層不應該從外層導入任何東西，這樣做的好處是，你可以對代碼的內層進行獨立測試。
好程序員的判斷
出貨能力
寫一個程序，算法非常精妙，代碼質量也非常高，但產出效率非常低，也不能算是一個號程序員。之前我看過一個所謂的大神，算法很溜，但做事根本沒辦法按時完成進度，這也不行。
優化能力
沒有一個程序，是一步到位的，很多時候隨著業務的增大，對性能的要求越來越高，有一定的代碼優化能力也是非常重要的。
調錯能力
項目越大，遇到的bug會越力氣，這時候就需要強大的debug能力，找出最為關鍵的錯誤點，甚至追溯底層框架的源碼。
bug是不可避免的，但一個好的程序員，基本上不會因為代碼數量的增多，而導致bug也同步增多，如果原本bug是10佔1，後來代碼增多了，變為100佔3，而不是100佔10.
技術掌控
你的項目能用spring，hibernate等等框架，但是對於這些技術，你真的掌控了嗎？假如有一點，框架版本需要升級，你做得到嗎？或者從hibernate轉為mybatis？
剩下的，一些非技術相關的能力，比如學習能力、抗壓能力，這裡就不多說了。
——摘自W3Cschool學員的回答
W3Cschool
好的代碼簡單明瞭，邏輯清晰，那麼好的代碼規範要求如下：
1、代碼是否符合業界通用規範，如Java語言的標識符的命名規範
1)、變量、方法：
1)、單個單詞：全部小寫
2)、多個單詞，首單詞小寫，其後的單詞首字母大寫，小駝峰標識
2)、類、接口： 所有單詞首字母均大寫，大駝峰標識
3)、包：小寫字母組成,域名反著寫
4)、統一的縮進
5)、變量、方法、類命名要見名知意
6)、良好的註釋
7)、大小寫敏感問題
2、可讀性強：代碼不是隻寫給自己看的，幾千上萬行代碼，幾個業務邏輯柔和在一起，要想改也不知道頭緒，看了半天才能繼續往下寫，將代碼拿給其他程序員看，在讀代碼期間，他向你提出的問題越少，說明這些代碼的可讀性也就越強。要想可讀性強，必須有良好的統一編碼風格！
3、代碼是否簡介，一個代碼能用一行的儘量不用2行
4、代碼是否可重用，同一個功能儘量不要在多處重複書寫。
5、代碼是否安全，代碼是否有考慮一些常見的安全問題和邊界問題，如SQL注入、XSS攻擊、CSRF攻擊等等。
6、性能是否好，你寫的代碼最終是要運行的，如果性能不好，是會影響用戶體驗的。
ITmian
我來說說我在工作中遇到的一個例子，某天因為業務需要，要修復一個bug，找到bug相關代碼，一看代碼，差點把我嚇死，大家猜猜怎麼著？一個定時工作的job類，五百多行代碼，只有一個方法，代碼中命名混亂，各種不在一個抽象層級的代碼混雜在一起，更讓人氣憤的是全篇沒有一行註釋！一看到這種代碼，就沒一點心情看下去了，奈何bug要修復啊，只能硬著頭皮看了，最後花了好長時間才找到問題原因，將bug修好，而我已經早已頭昏腦脹，不知道問候過多少遍這個奇葩的前輩了。
看完我這個實實在在的例子，要如何判斷一個程序員寫的代碼好不好，其實已經很清楚了！
首先要有完整清晰的代碼結構，起碼要一眼看上去要讓人有一種舒服的感覺！通篇一個方法是大忌，是絕對不允許的，儘量要將一些相關的代碼抽成方法，將一些基礎方法放到model類中複用。
其次，代碼中變量的命名要清晰有意義，無意義的變量命名會讓後來的代碼維護者頭破發麻，會讓代碼維護變得極為艱難，到時候可別怪人家問候你了。
然後就是註釋了，這也是很重要的一點，一個優秀的程序員首先要學會寫註釋，一個會寫註釋的程序員不一定是一個好的程序員，但一個不會寫註釋的程序員絕對不是一個好程序員！
所以，判斷代碼好不好，就要從以上幾個方面判斷！
大家有什麼看法，歡迎補充~
我是涼了個小秋，文青範的程序猿，歡迎關注，一起學習娛樂~
涼了個小秋
評判一段代碼寫得好不好，一般可以從以下幾個方面來看：
1、代碼書寫是否符合業界通用規範，如PHP代碼要符合PSR系列規範。
2、代碼是否簡潔，一段代碼能用一行實現的儘量不要使用兩行。
3、代碼是否可重用，同一個功能儘量不要在多處重複書寫。
4、代碼是否安全，代碼是否有考慮一些常見的安全問題和邊界問題，如SQL注入、XSS攻擊、CSRF攻擊等等。
5、性能是否好，你寫的代碼最終是要運行的，如果性能不好，是會影響用戶體驗的。
編碼之道
實際上也就是看程序員自己寫的代碼好不好，我覺得來衡量一段代碼好不好的可以從如下四個方面去分析。
1、規範性。規範性包含兩個方面，第一方面是：可讀性，因為代碼本身就是拿來讀的，結果你搞了一大段代碼，換個人去讀你的代碼，看了半天看不懂，那你說你自己的代碼再好，估計也沒人相信。第二方面是：就是一些變量名，函數名，類名等，比如Java裡，都是駝峰型，英文叫camel-case，如isEffecitve這種；然後還有就是不要“中西結合”，即拼音英文結合，讓人覺得非常雞肋。補充一點，就是關於可讀性，恰當的寫註釋，可能是一個比較好的idea。
2、效率。效率包含兩個方面，第一點就是時間複雜度，其實這個問題非常常見。我舉個小例子，比如，現在有一個需求，我們需要不斷地insert和delete，那我們是選擇ArrayList還是LinkedList呢，arrar刪除和insert的時間複雜度是O(n)，但是LinkedList則是O(1)。這個時候我們肯定是選擇LInkedList了，因為這種情況下，效率肯定是最低的。還有一種情況就是，冗餘代碼的情況，我們應該儘量不要在代碼裡寫一些無關的代碼，能簡潔，就儘量簡潔一些，起碼看起來乾淨點，更舒服。
3、可擴展性。這個問題，就需要我們在寫代碼前，心裡就應該對這塊業務的代碼的整體結構非常熟悉，需要考慮後續的一些業務擴展，需不需要改動非常多的代碼。記住一句話，“面向接口編程”。
4、還有最後一點就是，格式。現在很多IDE都可以幫我們格式化代碼，如果一段代碼格式非常亂，我們讀代碼的人是非常痛苦的，如果你看過這樣的代碼，肯定是非常有感觸的。
