thfghfg

對於一個程序猿來說，是必須要有評判代碼好壞的能力的，如果連評判代碼好壞的能力都沒有，那怎麼能寫出好的代碼呢？對於代碼評判的好壞，其實也就是對代碼質量的評價

如何評價代碼質量的好壞呢

平常評價代碼的好壞都會用到哪些詞彙呢，可擴展性、穩定性、可維護性、可讀性、可讀性高、可測性好、高內聚低耦合、穩定性、安全性、魯棒性等等，聽過的沒聽過的還有好多。其實瞭解的人知道這些詞彙都是從代碼的不同角度去說的，所以評判代碼應該從多個維度去說明。

常見的評判代碼質量的維度

• 可維護性

• 可擴展性

• 可讀性

• 靈活性

• 簡潔性

• 可複用性

• 可測試性

對於一段代碼函數或者類，為其編寫測試代碼的難易程度，或者編寫單元測試很困難，需要用到框架的高級特性才能實現，就叫做代碼的可測性。比如濫用靜態方法，耦合程度過高，使用複雜的繼承關係，濫用可變全局變量這些都是可測性差的代碼。

如何寫出高質量的代碼

要寫出高質量代碼，需要掌握更加明確細化的編程方法論，包含面向對象設計思想、設計原則、設計模式、編碼規範、重構技巧等。

測試軒

編程界有句名言：“計算機程序是寫給人看的，只是順帶計算機可以執行”。程序易讀，沒有花架子、沒有不必要的提前優化，這是通用的原則。

但是在工程實踐上，什麼是好的代碼，取決於代碼滿足要的需求的領域。

上圖是一段摘自我個人項目的 C 語言代碼（業餘時間寫作，非公司資產），可以看到用到了各種教科書都極力反對的 goto 語句，但實際上，如果是 C 語言比較熟練的話，使用 goto 語句可以大大簡化函數返回時的清理代碼，達到類似 C++ 語言 RAII 的效果。

再舉個例子來說，當你的工作是實現一個被廣泛調用的庫函數，比如 C 語言 malloc 這樣的內存分配函數，那麼，速度和內存使用效率就是就是最大的需求，函數實現可以使用各種醜陋的優化技巧甚至內嵌彙編等等，但只要滿足基本需求，這些破壞基本可讀性原則的手段就不會影響你的代碼成為一段好的代碼。

在滿足需求的前提下，我認為好的代碼還符合以下特徵：

1. 簡單性：能用簡單實現的方法就不要用複雜的方法，越簡單的代碼越容易維護；

   
   

2. 可讀性：無論是作者還是他人，都能很容易通過閱讀代碼瞭解到代碼實現的功能，且代碼的編寫沒有違反常理的地方；

3. 分層與模塊化：從架構的層面讓代碼易於理解與修改；

4. 優雅與簡潔：代碼在滿足功能需求的情況下儘量採用成熟的算法與邏輯，舉個例子，計算從 1 加到 100 的總和，優雅簡潔的方法是使用等差數列公式求和而不是用循環累加；

5. 效率：一般來說符合上面4條的代碼效率不會差，但也應把效率問題牢記在心，比如寫 Java 程序，如果遇到多次字符串相加的情況，隨時記得用 StringBuilder 來替換簡單的字符串連接。

以上是個人對好的代碼的幾點經驗，希望對大家有用。

命叔炸機

一段好的代碼，最少要遵守基本的編程規範，比如命名方式，注視等等，就拿變量名來說，必須讓人通過字面意思大概能知道這個變量是做什麼的，代表什麼意思，閱讀性要好，否則其他人看到代碼跟看天書一樣，完全不知道是在做什麼。同樣的，方法命名也是一個道理。

以下圖舉例來說，兩個方法都是檢查用戶名與密碼是否為空，但是第一個方法明顯規範於第二個方法，變量名就是賬號與密碼的英文單詞，一看就明白，而第二個方法以a，b，c來命名，沒人知道是啥意思，這種代碼是最差的。

allen5168

本人是軟件行業從業者，也經常考慮這個問題，正好借這個機會說一下個人的一些想法。個人認為好代碼，可能需要滿足一下一些條件：

第一，實現功能，我認為這也是最重要的。如果你寫的代碼連最基本的功能都沒實現，即使再漂亮再優雅，但一點實用性都沒有，這點不滿足的話，根本談不上好代碼。所以，我認為最大的質量就是實現功能，沒有實現功能，其他的都是白扯。

第二，排版合理。必要的縮進、換行、空行、空格和括號的對齊要合理，代碼有層次感。

第三、必要的註釋。類註釋，說明類的用途，類的作者，可能還有類的用法等說明。方法註釋，方法用途，方法作者，繼承說明，參數說明，返回值說明等等。變量註釋，主要說明變量的用途。代碼塊的註釋，簡明扼要的說明代碼的作用，讓其他人清楚明白。

第四、合理的命名規則。類的命名、方法的命名、變量的命名要有意義，易懂。

第五、編碼中需要注意的一些事項和遵循的原則。比如輸入流和輸出流的關閉，需要在finally中進行操作。比如在代碼中注意判空，防止NPE的出現。比如對大文件的處理，不要一下子讀入內存，防止內存爆掉。比如注意抽取常量，統一處理，便於維護。比如對異常，最好進行精細化處理，可針對不同進行不同操作等等。還有一些基本原則，比如單一原則，方法實現功能儘量單一。比如開閉原則，比如依賴倒置原則，比如接口隔離原則，比如DRY原則等等。

第六、設計模式的使用。合理的使用設計模式，可以減少你代碼的耦合度，提高代碼的擴展性，提高可維護性。另外，可藉助框架來減少你代碼的耦合度，比如我們經常提到的spring。

第七、合理的設計。進行必要的設計，但不會過度設計，讓代碼滿足當前的需求。好的架構一般是演化出來的，未必是一次設計出來的。

本人具有多年的java開發經驗，熟悉多種框架，熟悉網絡編程，熟悉java安全編程，熟悉大數據，熟悉多種安全協議，熟悉併發編程，有興趣的同學可以互相關注，互相學習！！！

代碼飼養員天齊

關於什麼是好代碼，軟件行業爛大街的名詞一大堆，什麼高內聚、低耦合、可複用、可擴展、健壯性等等。

一、也就是所謂設計6原則 — 迪米特法則（最少知道原則） 加上 SOLID :

1、Single Responsibility （單一職責）

2、Open Close（開閉）

3、Liskov Substitution（里氏替換）

4、Interface Segregation（接口隔離）

5、Dependency Inversion（依賴反轉）

二、函數不易太長

如果太長（一般不宜超過200行,但不絕對），你自己都不太容易讀懂，請不要猶豫，分解成模塊函數吧。

假設你的項目中有三個不同的層——內層、中層和外層。你的內容不應該從中層和外層那裡導入任何東西。中層不應該從外層導入任何東西 ，這樣做的好處是，你可以對代碼的內層進行獨立測試

三、變量名、函數名稱、類名、接口等命名含義不清晰

函數名能讓人望名知義，看名字就知道函數的功能是啥，以至於幾乎不需要多少comments最好

四、學習習慣

大黃哥兒

一個非常好的問題，我是工作多年的Web應用架構師，來回答一下這個問題。歡迎關注我，瞭解更多IT專業知識。

通用規則：實現功能、健壯、簡單、易讀、易維護。

詳細規則：見仁見智，可參照一些業界常用規則。

反面規則：《垃圾代碼19條法則》

急速馬力快de源碼客

在我看來，好的代碼分成這幾個層次：

實現功能（需求）

單純的把需求實現，只能算“合格”的代碼，如果要成為（初級）好代碼，我認為還需要做到下面幾點：

• 代碼的健壯性：需要多考慮規範要求以外的可能，我經常對組員說“不要相信別人，我們要把自己的代碼考慮全面”；比如開發一個接口，雙方已經約定某個字段是必傳的，那麼是相信對方系統會傳這個字段，還是“不要相信對方”，接口中增加非空判斷。

• 代碼效率：在工作期間，我發現很多開發人員很容易犯的一個錯誤，就是隻關注功能的實現，而不會考慮代碼執行效率；例如測試環境數據庫中有一萬的數據，隨便寫個SQL也不會發生效率問題，但是生產環境一千萬的數據，代碼一上生產就會出現問題（項目最好能提供一個準生產環境，或者生產環境的試運行）。

讓別人能看懂

一方面，軟件開發需要團隊合作，另外一方面，程序員崗位的流動性比較強，可能兩三年過後，項目組成員已經完全換了一撥人了；所以代碼容易閱讀，是很重要的。

• 遵守代碼規範：代碼分層、起名見名知意、代碼樣式等等；

• 準確的代碼註釋，接口必須有接口文檔；代碼修改之後，對應的註釋和文檔必須也對應修改；

少些代碼

少些代碼不代表讓你偷懶，要想寫出【好代碼】，一定不能只【看到代碼】。

• 深入瞭解需求，不合理的需求或者重複的功能，可以拒絕，或者給出其他的建議；
  

• 設計和寫代碼的時間投入，一定要合理安排，甚至有些時候，設計的時間翻到更長；

• 能複用的儘量複用，能抽象的儘量抽象，以便以後可以複用；

• 如果有經過實際考驗的【輪子】，那就直接拿來使用；

• 時刻要注意“過猶不及”：千萬不要學了什麼新的技術（框架、設計模式等），一定要用到項目中，而不是考慮是否合理，是否適用。

希望我的回答，能夠幫助到你！我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。

會點代碼的大叔

好代碼，滿足兩個條件：能實現預定效果、能被人容易看懂。

代碼的差別，不在於能否實現功能，更主要是實現的好壞。

有些代碼雖然實現效果了，但換個程序員就看不懂，無法維護，也是爛代碼。

現在的軟件業，程序員加班都是普遍現象，疲勞工作，勢必影響代碼質量。

大部分都在著急實現功能需求，完成領導安排的任務，只是以完成為目標。

這種不考慮長遠的工作方式，雖然短時間內達到了目的，但長期看問題很大。

程序員一旦離職，新來的需要花很久才能接手，項目的擴展性和穩定性都沒保證。

尤其一些外行的領導，一味地只知道做出來給上級邀功，不能科學的排期。

功能需求說改就改，新功能拍腦袋就來，導致項目設計不斷調整，損傷整體的架構穩定。

整個行業還沒意識到代碼質量的重要性，對代碼沒有敬畏之心，只看眼前不顧長遠。

只有行業人員達到飽和，把不合格的程序員和產品經理都淘汰下去，好代碼才能形成風氣。

臺哥彩鈴

面對這個問題，可能大多數程序員想到的是：高內聚，低耦合，可維護，易擴展。這些是對的，對於大部分IT從業者（尤其是剛入行，缺乏足夠知識和經驗的新人）來說，並不能通過一個具體的標準去衡量。

什麼樣的代碼才是好代碼？衡量代碼的好壞的指標或者維度有很多，比如性能好、架構好、高內聚等，這些指標的側重點各不相同，不同的開發人員的關注的重點也各不相同。

一方面是缺乏編程方面的經驗，在寫代碼時考慮的不夠全面，另一方面也有可能是需求的更改導致代碼的變動，這些都能影響代碼的質量，而代碼的質量會影響到產品的性能和好壞，接下來筆者與大家分享一些優質代碼的標準。

優質代碼就好比一本書，主旨貫穿全文，容易理解分章明確，要想寫出好的代碼，需要滿足以下標準：

1.明確性 ------ 代碼能夠做到不解自明。

2.可讀性 ------ 讓其它開發人員能夠看懂。

3.簡潔性 ------ 減少不必要的冗餘。

4.效率性 ------ 使代碼運行速度快。

5.維護性 ------ 容易修改升級。

一、代碼標準

1 明確性

明確性，質量較好的代碼，邏輯性相對比較的清晰，bug難以隱藏。要知道你所寫的每一段代碼是要幹什麼用的，有目的的去編寫程序，使程序整體有邏輯，在一些方法和屬性的命名時，儘可能的給予明瞭易懂的名稱，就像方法名採用動名詞組合一樣，從而提高可讀性。

2 可讀性

軟件開發往往不是一個人就能完成的，需要團隊的通力合作。可讀性，不只是你自己，還要讓其他開發、測試和運維人員能夠對所寫的代碼一目瞭然，儘可能的減少或不寫註釋。在出手之前先思考，不要寫出自己所不能理解的代碼，那樣只會加速系統的腐爛，做為一名程序員很有必要對自己所寫代碼進行思考和理解，從而對代碼進行整理提高簡潔性，好的代碼本身就是最好的說明文檔。

3 簡潔性

代碼中類和方法的長度要相對簡短，簡短的代碼活的更長久，沒有程序員不喜歡簡短的代碼，而且這樣出來的產品問題相對就會較少。

在一些方法中我們可能會遇到方法體過長的情況，一般來說高效的方法它的方法體不會過於太長，而太長的方法體，我們從中將其抽取分為兩個方法來進行調用，並且修飾符應該為private不能公開化，這樣做不僅能劃分業務邏輯，還能減少閱讀壓力，美化代碼，在下面樣例中如果不將方法體進行拆分，那麼代碼就會變得很臃腫，閱讀壓力大大增加，而進行規劃拆分後，就能很清晰明瞭的閱讀：

4 效率性

效率性，從一開始就要考慮程序性能，不要期待在開發結束後再做一些快速調整，在滿足正確性、明確性、可讀性等質量因素的前提下，設法提高程序的效率，在程序執行時讓代碼的執行速度較快，應以提高程序的全局效率為主，提高局部效率為輔。

5 維護性

所謂的維護性，就是指在系統發生故障後，在排查改正、改動、改進時的難易程度，維護性實際上也是對系統性能的一種不可缺少的評價體系。保證你所寫的代碼維護性相對較高，讓你和其他人修改起來比較簡單，而不是牽一髮而動全身。

6、命名

命名在一個項目工程中也影響著代碼的好壞，無論是包名、類名、方法名、變量名,命名的時候都應該考慮周全，實際開發過程中，我們的工程通常都會進行分包，其中一個功能模塊可能是一個或多個包組成的，這也就要求我們對包進行劃分同時還要規範命名

二、架構設計

1、代碼的高內聚

內聚是從功能角度來度量模塊內的聯繫，代碼關聯性比較強的代碼應該放在內聚在一起，形成一個獨立的功能模塊，可以是一個獨立的類，也可以是一個微服務。其實判斷代碼是否內聚一個比較簡單的方法就是看你能否給代碼或者服務給一個貼切的名字，如果代碼功能不內聚，我們是很難用一個簡短的名字來表示它的含義的。

2、代碼的低耦合

耦合性(Coupling)，也叫耦合度，是對模塊間關聯程度的度量。耦合的強弱取決與模塊間接口的複雜性、調用模塊的方式以及通過界面傳送數據的多少。模塊間的耦合度是指模塊之間的依賴關係，包括控制關係、調用關係、數據傳遞關係。模塊間聯繫越多，其耦合性越強，同時表明其獨立性越差。

耦合比較高的代碼危害比較大，最常見的表現就是改一個模塊的代碼會影響許多其它模塊，最終必然導致大家不敢修改舊的代碼，只能不停的添加新的接口，系統的可維護性非常差。

三、好代碼好處

1.功能模塊相對完整獨立，實現的邏輯性清晰，可讀性強。

2.多人合作開發的分工更加明確，開發速度較快，同時軟件質量高。

3.可以將模塊公用接口提升，充分利用可以複用的代碼。

4.可維護性強，避免修改一處代碼牽扯許多模塊，容易控制。

IT老田

好代碼這個概念太寬泛了。拋開需求以及架構等我覺得好代碼應該符號這幾個標準。

第一， 符號開發規範。別的開發語言不清楚，Java我還是有發言權的。比如大名鼎鼎的駝峰命名，代碼縮徑，以及每行字符長度等。符號規範的代碼更易閱讀，這樣哪天你換別的項目或跳槽交接起來也方便點。

第二，加合理的註釋。我一直認為註釋是屬於代碼的重要組成。沒有註釋的代碼是很難理解的。尤其是業務複雜的項目，當初你耗費幾周寫出的代碼，如果沒註釋，過一段時間再看也一樣會懵逼。

第三，選用合理的數據結構。對於數據結構沒有絕對的好與壞，只不過是使用場景不同罷了。當然最常用的數據結構也不過是List和Map。

第四，簡單易懂，一份好的代碼應該簡單易懂，而不是為了為了語法而寫。比如你雖然清楚記得運算符的優先級，但是為了可讀性還是要人為加括號。

以上就是我所認為的好的代碼。

關鍵字: 評判 科技 好壞