程式設計師無論是寫哪種語言的，都有條理清楚，註釋明瞭，格式規範的完美主義者; 也有雜亂無章，毫無註釋，格式隨意的浪蕩懶漢。

看到讓人讀起來很舒服不費勁，一目瞭然。而不好的程式碼，首先看到就讓人很眼花頭疼了，找個函式的大括號要找幾分鐘，你說說讓人怎麼受得了。程式設計師中有一句話:"怎麼把一個程式設計師逼瘋，最好的辦法就是讓他去讀別人的程式碼"。這裡別人的程式碼就是這種程式碼。程式碼規範寫好了，一方面讓自己看著很舒服，除錯也容易。其次現在程式開發都是好幾個人共同開發一個專案，你不按規範來對團隊穩定和團結也是有影響地。現在大部分網際網路公司為了規範程式碼都會有一套自己規範文件，在你進公司第一天，就會讓你嚴格按照規範文件寫程式碼，以此來規範程式碼和降低協同作業消耗。

寫程式碼的目的就是做產品的，程式碼規範了，最終還是要實現功能，完成產品的。所以好的程式碼可以用最少的，最簡單的程式碼實現。而不好的程式碼，會繞一大圈才實現或可能把自己都繞暈了而沒有實現，這是很正常的。所以就要加強邏輯和各種演算法練習和鍛鍊。

好的程式碼可以用較少的資源穩定的執行，效能有保證。而不好的程式碼，資源消耗比較大還不穩定，經常報錯或宕掉。可能報的錯自己都不知道為什麼。所以需要不斷調優耗時費力。當然效能方面和程式設計師的經驗和水平高低分不開的，可以透過長期經驗的積累對效能最佳化不斷提高。

所以判斷程式碼好壞的質量，實際上是對該程式設計師水平，經驗和素養的考量。對的人才能做對的事情。

好程式碼的判斷標準

從機器的角度判斷一個程式設計師程式碼好不好，標準是正確性和效能——程式碼要能按照預期正確工作 實現功能同時效能也滿足要求。

從人的角度 工程角度 商業角度，程式碼好不好的判定標準是可維護性、可複用性、可擴充套件性——程式碼清晰易懂（容易被其它程式設計師或幾個月後的自己讀懂）出現問題時 能以可接受的成本排查和修復其中的問題、出現類似需求時 容易被其它模組或系統複用以節省開發成本、需求變化時能夠以可接受的成本被改造喝擴充套件以滿足。

大家經常提到的命名規範 註釋之類的 我就不重複了，這裡我提一個大家不經常提到但很重要的點——高內聚：其實OO面向物件設計理論中 對高內聚低耦合已經很強調了，但是我發現大多數人只注意到了低耦合 而忽視了或沒有深刻理解高內聚！

所謂高內聚 我的理解是：同一層面的業務邏輯要聚集在一處。

總有人強調註釋，好的程式碼根本不需要太多註釋！

第一是規範，命名規範及書寫規範；第二是合理的架構；第三是良好效能；第四在設計和效能之間有較好的平衡。吹一下，我其實也是外行。

1 ：好的程式碼看起來就像藝術品，能給讀者一種很舒服的感覺。

2：特別符合程式碼規範，該縮排的地方要縮排，字母大小寫要遵守，變數採用大駝峰還是小駝峰要統一。

3: 可讀性強，函式功能要有說明，傳入引數傳出引數含義和格式要明確，都要有備註；變數定義呀函式名稱呀更要可讀，類似isDIgit判斷是否是數字，就非常的易讀好記。

4：健壯性要強，比如對於輸入的變數要檢查，異常情況要考慮全，不能 core掉。

第一，能夠使用靜態程式碼檢查外掛阿里規約外掛、findbugs、checkstyles、sonarqube等，用來改進自己的程式碼，並且把常見問題規避掉。這裡應該能夠解決掉80%的常見程式碼程式設計問題。

第二，能夠站在巨人的肩膀上，把已經總結出來的程式設計習慣和原則思想應用到自己的程式碼裡面，例如程式碼整潔之道，重構，Effective Java，設計模式等書中提及的習慣思想等

第三，能夠熟練操作各種程式設計工具和外掛，迅速而又準確的定位程式碼，解決問題

2002曾經接管過一家電路板廠的ERP程式碼，經過了兩個月的通宵達旦，終於成功控制住程式碼，箇中的滋味自己慢慢體會。

一個程式設計師寫的程式碼好與不好，有以下幾方面

據我見過的程式設計師很多寫程式碼都不註釋的，只有那些高手才喜歡註釋。如下圖

如果程式碼不註釋，面對專案幾十萬行的程式碼，一個星期或更長時間回頭一看，連自己都找不到看不懂，更何況是團隊作戰。

一個程式碼不註釋，程式碼的可讀性變差，排查Bug的時候變得困難重重，花費的時間成本大大增加。

在專案中命名的標準化非常重要，比如窗體、控制元件、變數、過程、函式類等都要命名標準化。

如果執行命名標準化，則對系統進度及效率大大提升，如下圖：

程式碼的可讀性除了註釋之外，還有一個可擴充套件、可複製性。也就是把相同屬性的程式碼封裝在函式、過程、單元或類中。例如：你要建一個通用的儲存功能介面，首先建一個父介面，假設它包含了儲存、取消按鈕，那你以後每建一個類似介面的時候，只要引用它，所有的介面都有個儲存、取消按扭，同時將相同的程式碼封裝在按鈕過程中。

這個就是程式設計的重要概念一繼承。

比如說程式碼的字母大小寫✍，段落的佈局，程式設計介面的佈局等。問題不大，自己個人可以定製適合團隊標準即可。

高內聚，低耦合。介面要做到像數學定理那樣完備和簡潔。抽象要合理，符合業務領域。設計能做到提前準備和應對需求變化。排版美觀，程式碼自注釋，註釋對關鍵思想的傳達。巧用語言特性，但是要避開語言的陰暗角落。經常重構，改善程式碼結構，避免程式碼開始向腐爛的方向發展。就像養花一樣，有爛葉子就剪，有蟲子就抓。最小驚訝原則，讓別人覺得是正常路數或者捷徑，不要讓別人覺得是歪門邪道。避免屎山化。符合SOLID原則。最基本的，不要讓接手者詛咒你。

一個系統的程式碼好與不好，不是一個程式設計師決定的。

其實， 泛泛的說程式碼好壞，沒有意義。

比如，一個針對提高執行速度有特殊要求模組，根本不必考慮其他人的閱讀理解。

又比如，應用邏輯的實現，策略化、規則化、流程化，需要嚴格的遵守規範，程式碼審查合規工作，比寫程式碼更重要。因此，程式碼的可讀性就比較重要。

而策略引擎、規則引擎、流程引擎，等等，基礎程式碼的可讀性就不是主要問題了。

第一，程式碼規範很重要。第二，程式碼一定要註釋清楚。第三，能否透過程式設計模式簡化程式碼，提高程式碼複用性，如果用了程式設計模式程式碼還是一團糟那就是裝逼。第四，演算法效率高，能精簡的就精簡，總之就是要儘量減少消耗。第五，能從架構方面最佳化專案，架構設計從很大程度上決定了專案能否走得更遠，比如說後續的可擴充套件性。

程式碼質量是判斷一個產品是否是精品的標準之一，也是程式設計師的門面，定義一個好的程式設計師要看他寫的有效程式碼有多少，可以從以下幾個方面判斷一個程式設計師程式碼寫的好與不好。

程式碼規範：程式設計師寫程式碼時一定要遵守程式碼規範，程式碼規範能使你寫的程式更加優雅，更加清晰易懂，要讓別人能從你寫出的程式碼中看懂你的思路。

程式碼邏輯：程式碼邏輯一定要簡潔易懂且全面，考慮場景要到位，寫的時候邏輯混亂就會導致使用時候報錯。

程式碼效能：一個好的產品一定要經得起大資料的考驗，不是簡單幾個資料就證明這個功能是好使的。還要考慮效能方面，程式碼的好壞能直接影響到產品效能。

程式碼安全：安全性一定要有保證，客戶使用產品就是把它們業務的主要資料都交付到了產品中，所以產品是否安全是客戶要考慮的基本條件之一，編寫程式的時候就要考慮到產品的安全性。

幾乎所有的事情能不能做好，關鍵在於事前規劃設計，寫程式碼也是這樣：設計優先、設計評審確認、工作分解合理，然後用測試用例倒逼設計是否合理可行；另外，充分、負責的測試是好的程式碼程式的保障。活到老學到老、進無止境、對於程式匠人也是如此。

一個“程式碼風騷、效率恐怖”的優秀程式設計師可以抵十個普通程式設計師。我在軟體江湖混跡多年，見過形形色色的程式設計師。濫竽充數的程式設計師很好識別，程式碼寫得很好的程式設計師同樣容易判斷，程式碼終究是程式設計師腦袋裡的思維體現。 多年來，我見過程式碼寫得好的程式設計師均有以下特點：

1.喜歡擼程式碼，以程式設計為樂。從來沒見過討厭程式碼的優秀程式設計師，沒興趣肯定做不好。

2.能迅速理解需求，並在短時間內把需求實現為程式碼。

3.寫的程式碼結構清晰、合理，邏輯準確嚴謹，可讀性高，程式碼結構是大腦思維的輸出，如果腦袋裡想清楚了，反映到程式碼裡當然同樣清楚。

4.會認真考慮程式碼的執行效率。

5.能很好地解決專案中最複雜的問題。

6.優秀的程式設計師不僅程式碼寫得好，讀程式碼、理解別人程式碼的水平也很高，一個專案由很多程式碼構成，專案組程式設計師之間互相呼叫各自的程式碼是常見的事情，優秀的程式設計師不僅能寫好自己的程式碼，同時也能很好地理解別人的程式碼及介面，從而順利推進整個專案的進度。

7.沒有bug的軟體是不存在的，全世界每天都在使用的微軟的Windows依然需要不停地改bug、堵漏洞、打補丁。優秀的程式設計師能運用靈活多變的除錯技巧快速定位bug，並準確找出bug發生的根本原因，從而解決bug。

其實在企業中優秀的程式設計師還是比較好辨別的，大家都知道一個優秀的程式設計師的產能要高几倍，甚至更多。我們一起聊聊程式設計師編寫程式碼有哪些特點？

1、程式設計師在企業編寫程式碼質量高，邏輯清晰，層次分明，易擴充套件、易遷移、易複製，線上執行故障率和bug率都特別少，這種程式設計師平時看起來應該比較清閒，就是別人眼中的閒人，不平衡的物件；

2、程式設計師在企業編寫的程式碼簡潔幹練，業務邏輯個函式註釋豐富，好像這樣的程式設計師寫的程式碼任何其他人都可以輕鬆的接手，這樣的程式設計師看起來誰都可以替代；

3、程式設計師在企業編寫的程式碼亂七八糟，毫無邏輯可言，review後你有打人的衝動，這種程式設計師每天忙於各種線上救場救火，線下風風火火修改bug，累成龜孫兒，加班通宵絕不挑剔，時間久了既然成了公司裡面的靚仔，領導層人人愛，還能當教材讓大家學習，沒準兒還能評一個勤勞小蜜蜂的榮譽稱號；

4、程式設計師在企業程式碼質量不高，不遵循編碼規範，註釋率不高，邏輯不清晰，程式碼除了他沒人能看懂，時間長了成了公司裡面的唯一，誰也無法將它替代；

程式猿用的是什麼語言，C、Java、Python、SQL？

找個不會該語言的猿去閱讀維護，如果還行，說明程式碼寫的還好。

程式設計師寫的程式碼質量好壞可以從兩個角度入手

1.好的程式碼一般通俗易懂

高手總會化繁為簡，寫的程式碼首先是能讓人看懂，谷歌蘋果的工程師程式碼提交之前都會找上週圍的同時給看一遍，如果對方覺得沒有什麼問題可以直接提交，並且在提交註釋裡面寫上reviewer名字，這樣同時也把責任給擔起來了，看似一個很簡單的模式，卻被絕大部分技術公司沿用。

所以程式碼不能只有自己能看懂，讓別人能看懂你的思路，你的設計意圖。

2.好的程式碼，遵守整個系統編碼規範，不出格，最重要的一點好的程式碼能夠經得起實踐的考驗，在實際運轉過程中，沒有很重大的系統崩潰出現才能稱得上好程式碼

所以程式碼不能只是看著好，在效能上也需要有不俗的體現，對於程式設計師來講程式碼就是臉面，特別是在團隊配合之中，如果一個人寫的程式碼質量高就會給人形成一種靠譜的感覺，在配合過程中也比較容易形成默契的感覺，一看誰寫的程式碼如果平時程式碼質量高，大家在呼叫該模組的時候會覺得很舒心，很放心。程式碼直接關係著程式設計師的品質問題了，有很多老程式設計師對於程式碼質量非常關注，不允許自己犯一些很低階的錯誤，導致自己的名譽受損。

一個程式寫的好不好，需要多方面考慮。

可讀性。一個讓別人看的非常費勁的程式碼不是好程式碼。也許自己過段時間也會看不懂。

健壯性。bug滿天飛的程式碼，肯定不好。比如 "".equals(obj)絕對比obj.equals("")好。

擴充套件性。程式中不要有死程式碼。

1.程式碼佈局工整，這個應該都能做到。

2.模組化寫程式碼，把一個個功能進行模組化，方便找bug和修復。

3.邏輯思維，邏輯好的可能幾句程式碼就解決一個功能，但邏輯不好的可能需要幾十行或更多的程式碼來實現，這個得多練。

4.底層知識掌握程度，這個會影響程式的崩潰，出錯，卡頓，計算速度。底層知識過硬可以很好的避免。

5.多練可以提高效率和降低bug，如果是一個新手，一句程式碼幾個十幾個bug都很正常

我想把這個問題轉化為兩個部分：第一個部分是怎麼判斷程式設計師的程式碼好不好，第二部分想說說什麼樣的程式設計師，才是好的程式設計師。

好的程式碼，就像是小說家手中的短篇小說，邏輯清晰，簡單明瞭，卻又能觸動心靈，而壞程式碼，就像是一輛外表富麗的老舊汽車，開不動不說，隨時還有散架的危險。

究竟什麼樣的程式碼才能算是好程式碼？這是一個很有爭議的話題，每個人的理解可能都不一樣，所以制定一個符合自己部門要求的規範，有了依據，寫出來的程式碼才有可能成為好程式碼。

思考了一下題主提問題的場景，應該有兩種情況。一種是，就是自己本身不懂程式碼，只是想知道怎麼判斷一個程式設計師的程式碼質量另外一種情況，自己本身就是程式設計師，可能是剛學不久，不知道怎麼判斷好程式碼的標準。

如果你不懂程式碼，那就直接判斷這個程式設計師是不是好程式設計師吧，判斷程式碼，也不是你可以做的事。下面我會提到這一點。

可讀性

好的程式碼本身就是最好的說明文件——Steve McConnell

程式碼幾千行，所有業務邏輯全部揉在一起，除了你沒人看得懂，週末想續寫程式碼，結果發現連自己也要看半天，才能接著寫下去，這樣的程式碼，能是一個好程式碼嗎？

判斷：將程式碼拿給其他程式設計師看，在讀程式碼期間，他向你提出的問題越少，說明這些程式碼的可讀性也就越強。

要想讓部門所有人寫出的程式碼可讀性強，就必須制定一個統一的開發風格，這樣不管是老程式設計師還是新程式設計師，都能快速上手，可讀性也會得到一定的保障。

可維護性

曾經看過一段程式碼，一個method幾千行程式碼，沒有人敢維護，修改一點點就會發生不可知的錯誤，程式碼又臭又長，除了重構，完全沒有辦法。這樣的程式碼，就是一個差到不行的程式碼。

判斷：一般有三點可以做個大概的判斷，一是易讀，二是可拓展，三是資料靈活，四是可追蹤。

簡潔性

很多程式設計師之所以喜歡寫長程式碼，主要是寫起來沒什麼障礙，也不用怎麼思考，跟記流水賬一樣。還有就是學習的時候，養成了一些不良的程式設計習慣，亦或是習慣成自然，已經不知道自己所寫的程式碼，是不是夠簡潔了。

判斷：拿出以前寫過的程式碼，讀一下，看看是不是簡潔了，如果是，至少說明你現在寫的程式碼，比以前簡潔了。

模組化

好的程式碼，都是模組化的。假設你的專案有三個不同的層，分別為內層、中層和外層。你的內容不應該從中層和外層那裡匯入任何東西。中層不應該從外層匯入任何東西，這樣做的好處是，你可以對程式碼的內層進行獨立測試。

出貨能力

寫一個程式，演算法非常精妙，程式碼質量也非常高，但產出效率非常低，也不能算是一個號程式設計師。之前我看過一個所謂的大神，演算法很溜，但做事根本沒辦法按時完成進度，這也不行。

最佳化能力

沒有一個程式，是一步到位的，很多時候隨著業務的增大，對效能的要求越來越高，有一定的程式碼最佳化能力也是非常重要的。

調錯能力

專案越大，遇到的bug會越力氣，這時候就需要強大的debug能力，找出最為關鍵的錯誤點，甚至追溯底層框架的原始碼。

bug是不可避免的，但一個好的程式設計師，基本上不會因為程式碼數量的增多，而導致bug也同步增多，如果原本bug是10佔1，後來程式碼增多了，變為100佔3，而不是100佔10.

技術掌控

你的專案能用spring，hibernate等等框架，但是對於這些技術，你真的掌控了嗎？假如有一點，框架版本需要升級，你做得到嗎？或者從hibernate轉為mybatis？

剩下的，一些非技術相關的能力，比如學習能力、抗壓能力，這裡就不多說了。

——摘自W3Cschool學員的回答

作為一名從事網際網路行業多年的老程式設計師，我來回答一下這個問題。

在我看來程式設計師程式碼的好壞標準也與計算機行業的發展有密切的關係，早期的程式設計師非常注重程式碼的執行效率，比如時間複雜度和空間複雜度等，當前的程式設計師對程式碼的可讀性和規範性也非常重視，因為目前的軟體開發都是團隊行為，團隊合作一定要有規範性的程式碼要求。

我目前對團隊程式設計師的程式碼要求主要集中在以下幾點：

第一，程式碼的規範性。所謂程式碼的規範性指的就是程式碼的模組清晰、可讀性強、格式良好、命名合理、註解詳細。程式碼的好壞第一眼是模組劃分是否清晰，然後是格式，再然後是邏輯是否清晰。如果這段程式碼執行的結果是正確的，但是邏輯混亂，這樣的程式碼就不是好的程式碼，這也是很多初級程式設計師經常犯的錯誤，如果不及時指正，對他未來的發展會非常不利。

第二，程式碼的執行效率。程式碼的執行效率往往體現了一名程式設計師的能力，不同的程式碼在執行效率上差距非常大。程式碼的執行效率涉及到時間複雜度、空間複雜度，對演算法的選擇和實現思路決定了程式的執行效率。有經驗的老程式設計師往往在執行效率上有多套完整的解決方案，這是年輕程式設計師需要重點學習和提高的地方。

第三，程式碼的擴充套件性。程式碼的擴充套件性主要體現在程式碼結構的設計上，運用規範的模式能夠在很大程度上保證程式碼的擴充套件性。程式沒有不修改的，修改就涉及到功能的擴充套件，而好的程式碼在功能擴充套件上就比較方便。比如在完成一個簡單的資料存取功能的時候，程式設計師會按照實體類、介面、實現類、工廠類的結構來設計，這樣以後的擴充套件會非常簡單。

最後，不同的開發團隊往往有不同的規範要求，程式設計師一定要仔細學習並掌握，這對以後的團隊合作非常重要。作為軟體團隊的一份子，一定要記住不要犯低階錯誤！

如果有開發方面的問題，或者是考研方面的問題，都可以諮詢我。

很多人不是天生就能寫一手好程式碼，特別是剛開始工作一兩年的程式設計師。如果公司不注重程式碼質量，只需要簡單寫下注釋，沒有程式碼review的喜歡，那提高程式碼質量全要靠自己了。

好的程式碼一般簡潔，邏輯清晰，規範，設計模式運用得好。

一般公司會從你的程式碼質量評估你的個人能力，推薦看下阿里巴巴java程式碼規範，網上有相應文件，還有相關書籍，比如《重構改善現有程式碼設計》，《effective java》等書籍，對提升程式碼質量很有幫助。

這個要是外行人，一般很難判斷的，如果是同行，那麼會去分析它的邏輯，演算法，因為演算法是程式的靈魂，然後再分析程式碼的質量，可讀性，註釋，程式碼重用性，還有程式語言特性他是否掌握，因為每一種程式語言特有的特性都會有差異。