風亂語
好代碼的判斷標準
從機器的角度判斷一個程序員代碼好不好，標準是正確性和性能——代碼要能按照預期正確工作 實現功能同時性能也滿足要求。
從人的角度 工程角度 商業角度，代碼好不好的判定標準是可維護性、可複用性、可擴展性——代碼清晰易懂（容易被其它程序員或幾個月後的自己讀懂）出現問題時 能以可接受的成本排查和修復其中的問題、出現類似需求時 容易被其它模塊或系統複用以節省開發成本、需求變化時能夠以可接受的成本被改造喝擴展以滿足。
大家經常提到的命名規範 註釋之類的 我就不重複了，這裡我提一個大家不經常提到但很重要的點——高內聚：其實OO面向對象設計理論中 對高內聚低耦合已經很強調了，但是我發現大多數人只注意到了低耦合 而忽視了或沒有深刻理解高內聚！
所謂高內聚 我的理解是：同一層面的業務邏輯要聚集在一處。
自信中國人上海程序員
寫了十多年代碼，見過很多爛代碼，也見過不少優秀的代碼，那麼如何判斷代碼的好與壞呢，我談談自己的看法。
好的代碼，就算外行看到也會說是好代碼
首先，好的代碼會嚴格遵守代碼規範。從代碼的格式、命名、註釋，就能看出來代碼的好壞：遵守代碼規範的代碼不一定好代碼，但好代碼一定會遵守代碼規範。
所以我經常說，好的代碼，讓一個外行人看，就算他看不懂寫的什麼，但是他也會說寫的不錯。
實現需求，並考慮可擴展性
代碼必須要實現需求，這是及格線，對於好的代碼，評定標準會更高。
舉個簡單的例子：
客戶提了一個需求，查詢展示客戶列表，對於賬戶餘額超過10萬的客戶，標紅展示。
代碼也很容易，餘額>=10萬{特殊處理}。
過幾天，需求說，10萬這個標準有些低了，變成50萬吧。
然後改代碼，餘額>=10萬{特殊處理}，然後上線。
又過了幾天，需求說，50萬有些高了，調整成30萬吧...
如果把這個限額標準做成可配置的，是不是就靈活很多。（你要是把配置放在數據庫中，每次判斷去查詢的話，你還是寫死在程序裡面吧）
我們圈子裡就有一個傳言：一個優秀程序員的品質，就是可以準確的蒙對客戶要變化的需求。
注重業務功能，也要注重代碼效率
工作十多年，我遇到很多這樣的程序員：一心一意實現業務邏輯，在測試環境跑的沒有問題，一上生產就卡死。因為測試環境有一千條數據，生產環境有一千萬條數據。
所以好的代碼，會根據實際生產環境的實際情況，進行一定程度的設計和優化。（優化是無止境的，適度就好）
我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。
會點代碼的大叔
由題目審題得知：評判對象為程序員，評判內容為其下的代碼；
那麼在沒有明說初級程序員、高級、資深，還有具體技術定向的情況下，提問者應該就是問的針對編程這項工作而言，具有普遍通用的評判標準：下面就來列幾條具有普遍適應性的評判標準：
1、代碼註釋：這一點是很簡單的一點、也是適用性很強的一點；無論是個人編程還是公司業務、核心技術研發、科研等等類型的項目都需要，好的註釋會使得代碼可讀性強，易於代碼的交接、複用。
2、命名規範：命名規範，有文檔的、項目的、資源文件的、類的、函數的、變量、常量等等，之所以放到第二位是因為，適用於代碼的好的命名規範，一般具有唯一性（不會產生歧義），專業性、簡潔性等特點，能讓項目代碼協同工作人員一眼讀懂其所代表的含義，在相同作用域下不會與類似作用功能的函數、變量等，產生命名衝突和歧義。
3、編程風格：編程風格大公司一般都會有具體要求，其中命名規範也是其中一點；拆開講是為了內容簡潔;簡單講幾點：1、代碼對齊格式 2、函數{}的使用，代碼段的設置 3、字符串、sql語句的編寫規範 4、返回值，函數類型（這個放進來比較勉強）5、如果再往大了說，文件組織等（偏向於架構風格）
4、代碼性能：也可以說是代碼執行效率；這個就得視具體項目及應用環境的限制了，主要還是看在空間利用率和時間執行效率上的性價比。
5、耦合性：特別是業務型的項目很注重，現在普遍採用微服務的架構模式，主要也是為了滿足低耦合的要求；代碼耦合性高，會造成可維護性特別差！包括對代碼的業務/功能拓展，性能優化、重構等等。
6、複用性、可移植性：一個偏向於（Java、.net等）一個偏向於c一類的編程語言及技術；複用性需要做好低耦合比較容易達到，如：減少對輸入參數、輸入參數類型申明為泛型、返回值類型返回泛型等。可移植呢：多用於嵌入式移動設備的底層編程、驅動、內核、網絡、文件等底層架構基礎編程。
這幾點可能不全，但是基本做到了能較為普遍的覆蓋大多數的代碼評判標準了。
清風竹下歲月
1 ：好的代碼看起來就像藝術品，能給讀者一種很舒服的感覺。
2：特別符合代碼規範，該縮進的地方要縮進，字母大小寫要遵守，變量採用大駝峰還是小駝峰要統一。
3: 可讀性強，函數功能要有說明，傳入參數傳出參數含義和格式要明確，都要有備註；變量定義呀函數名稱呀更要可讀，類似isDIgit判斷是否是數字，就非常的易讀好記。
4：健壯性要強，比如對於輸入的變量要檢查，異常情況要考慮全，不能 core掉。
古城老王
我來說說我在工作中遇到的一個例子，某天因為業務需要，要修復一個bug，找到bug相關代碼，一看代碼，差點把我嚇死，大家猜猜怎麼著？一個定時工作的job類，五百多行代碼，只有一個方法，代碼中命名混亂，各種不在一個抽象層級的代碼混雜在一起，更讓人氣憤的是全篇沒有一行註釋！一看到這種代碼，就沒一點心情看下去了，奈何bug要修復啊，只能硬著頭皮看了，最後花了好長時間才找到問題原因，將bug修好，而我已經早已頭昏腦脹，不知道問候過多少遍這個奇葩的前輩了。
看完我這個實實在在的例子，要如何判斷一個程序員寫的代碼好不好，其實已經很清楚了！
首先要有完整清晰的代碼結構，起碼要一眼看上去要讓人有一種舒服的感覺！通篇一個方法是大忌，是絕對不允許的，儘量要將一些相關的代碼抽成方法，將一些基礎方法放到model類中複用。
其次，代碼中變量的命名要清晰有意義，無意義的變量命名會讓後來的代碼維護者頭破發麻，會讓代碼維護變得極為艱難，到時候可別怪人家問候你了。
然後就是註釋了，這也是很重要的一點，一個優秀的程序員首先要學會寫註釋，一個會寫註釋的程序員不一定是一個好的程序員，但一個不會寫註釋的程序員絕對不是一個好程序員！
所以，判斷代碼好不好，就要從以上幾個方面判斷！
大家有什麼看法，歡迎補充~
我是涼了個小秋，文青範的程序猿，歡迎關注，一起學習娛樂~
幻境少年
代碼好與不好，要看代碼在實現功能的同時，能不能很好的支持後面功能的維護和擴展。這裡涉及到代碼設計的6大基本原則：
1. 單一職責原則
一個類或者一個接口，最好只負責一項職責
2. 開閉原則
一個軟件實體如類、模版和函數應該對擴展開放，對修改關閉
3. 里氏替換原則
原則包含了一下四層含義：
- 子類可以實現父類的抽象方法，但不能覆蓋父類的非抽象方法；
- 子類可以增加自己特有的方法；
- 當子類的方法重載父類的方法時，方法的形參要比父類方法的輸入參數更佳寬鬆；
- 當子類的方法實現父類的抽象方法時，方法的返回值要比父類更加嚴格；
4. 依賴倒置原則
高層模塊不應該依賴低層模塊，二者都應該依賴其抽象；抽象不應該依賴細節；細節應該依賴抽象，其核心思想是依賴於抽象；
5. 接口隔離原則
一個接口只服務於一個子模塊或業務邏輯，服務定製。也就是說建立單一接口，不要建立龐大臃腫的接口，儘量細化接口，接口中的方法儘量少。
6. 迪米特法則
一個對象應該對其他對象保持最少的瞭解。就是一個對象對自己需要耦合關聯調用的類應該知道的少；這會導致類之間的耦合度降低，每個類都儘量減少對其他類的依賴
除了上述所說代碼設計的幾大基本原則外，還有以下代碼習慣需要遵循：
1. 註釋
代碼首先要儘量具備自注釋功能，如果確實無法自注釋，需要增加必備註釋，減少廢話註釋；
代碼註釋需要隨著修改而更新。
2. 命名和格式
遵循統一的命名風格，統一的縮進格式，代碼一目瞭然，閱讀代碼也會無比舒心。
3. 團隊協作
團隊協作項目中，儘量使用常用的用法，不影響效率的情況下，儘量減少太高級的用法。
4. 架構和解耦
大型工程，架構和解耦非常重要，使用合理的架構，將功能模塊化，擴展和維護，只需要修改對應的模塊和文件。
代碼猩球
第一，能夠使用靜態代碼檢查插件阿里規約插件、findbugs、checkstyles、sonarqube等，用來改進自己的代碼，並且把常見問題規避掉。這裡應該能夠解決掉80%的常見代碼編程問題。
第二，能夠站在巨人的肩膀上，把已經總結出來的編程習慣和原則思想應用到自己的代碼裡面，例如代碼整潔之道，重構，Effective Java，設計模式等書中提及的習慣思想等
第三，能夠熟練操作各種編程工具和插件，迅速而又準確的定位代碼，解決問題
AliceBillCindy6688
程序員寫的代碼質量好壞可以從兩個角度入手
1.好的代碼一般通俗易懂
高手總會化繁為簡，寫的代碼首先是能讓人看懂，谷歌蘋果的工程師代碼提交之前都會找上週圍的同時給看一遍，如果對方覺得沒有什麼問題可以直接提交，並且在提交註釋裡面寫上reviewer名字，這樣同時也把責任給擔起來了，看似一個很簡單的模式，卻被絕大部分技術公司沿用。
所以代碼不能只有自己能看懂，讓別人能看懂你的思路，你的設計意圖。
2.好的代碼，遵守整個系統編碼規範，不出格，最重要的一點好的代碼能夠經得起實踐的考驗，在實際運轉過程中，沒有很重大的系統崩潰出現才能稱得上好代碼
所以代碼不能只是看著好，在性能上也需要有不俗的體現，對於程序員來講代碼就是臉面，特別是在團隊配合之中，如果一個人寫的代碼質量高就會給人形成一種靠譜的感覺，在配合過程中也比較容易形成默契的感覺，一看誰寫的代碼如果平時代碼質量高，大家在調用該模塊的時候會覺得很舒心，很放心。代碼直接關係著程序員的品質問題了，有很多老程序員對於代碼質量非常關注，不允許自己犯一些很低級的錯誤，導致自己的名譽受損。
大學生編程指南
Java程序員中非常流行阿里巴巴Java編碼規範，這是阿里對Java程序員的規範要求，一公佈引起很大反響，筆者作為把阿里規範看了不下五遍的人，不得不承認如果代碼能按照編碼規範來寫，那將是非常優秀的。不僅僅是影響了代碼的整潔度，有些規範的編寫將非常有利於軟件的性能和穩定性。
判斷代碼好壞我有以下幾個方法:
- 首先先看代碼的規範性，比如駝峰寫法，比如是否在每個接口處都帶有註釋。這些可以用阿里插件掃描。
- 其次，可以用sonar等工具進行掃描，看看代碼是否有空指針的可能性，還有些“壞味道”的代碼。
- 最後，可以看看這些代碼的細節，具體實現方式，在核心算法裡有沒有註釋，是否冗餘，是否會有更好的寫法替代。
關注“極客宇文氏”更多幹貨經驗分享。極客宇文氏
好的代碼簡單明瞭，邏輯清晰，那麼好的代碼規範要求如下：
1、代碼是否符合業界通用規範，如Java語言的標識符的命名規範
1)、變量、方法：
1)、單個單詞：全部小寫
2)、多個單詞，首單詞小寫，其後的單詞首字母大寫，小駝峰標識
2)、類、接口： 所有單詞首字母均大寫，大駝峰標識
3)、包：小寫字母組成,域名反著寫
4)、統一的縮進
5)、變量、方法、類命名要見名知意
6)、良好的註釋
7)、大小寫敏感問題
2、可讀性強：代碼不是隻寫給自己看的，幾千上萬行代碼，幾個業務邏輯柔和在一起，要想改也不知道頭緒，看了半天才能繼續往下寫，將代碼拿給其他程序員看，在讀代碼期間，他向你提出的問題越少，說明這些代碼的可讀性也就越強。要想可讀性強，必須有良好的統一編碼風格！
3、代碼是否簡介，一個代碼能用一行的儘量不用2行
4、代碼是否可重用，同一個功能儘量不要在多處重複書寫。
5、代碼是否安全，代碼是否有考慮一些常見的安全問題和邊界問題，如SQL注入、XSS攻擊、CSRF攻擊等等。
6、性能是否好，你寫的代碼最終是要運行的，如果性能不好，是會影響用戶體驗的。
