thfghfg
好代碼，滿足兩個條件：能實現預定效果、能被人容易看懂。
代碼的差別，不在於能否實現功能，更主要是實現的好壞。
有些代碼雖然實現效果了，但換個程序員就看不懂，無法維護，也是爛代碼。
現在的軟件業，程序員加班都是普遍現象，疲勞工作，勢必影響代碼質量。
大部分都在著急實現功能需求，完成領導安排的任務，只是以完成為目標。
這種不考慮長遠的工作方式，雖然短時間內達到了目的，但長期看問題很大。
程序員一旦離職，新來的需要花很久才能接手，項目的擴展性和穩定性都沒保證。
尤其一些外行的領導，一味地只知道做出來給上級邀功，不能科學的排期。
功能需求說改就改，新功能拍腦袋就來，導致項目設計不斷調整，損傷整體的架構穩定。
整個行業還沒意識到代碼質量的重要性，對代碼沒有敬畏之心，只看眼前不顧長遠。
只有行業人員達到飽和，把不合格的程序員和產品經理都淘汰下去，好代碼才能形成風氣。
臺哥彩鈴
編程界有句名言：“計算機程序是寫給人看的，只是順帶計算機可以執行”。程序易讀，沒有花架子、沒有不必要的提前優化，這是通用的原則。
但是在工程實踐上，什麼是好的代碼，取決於代碼滿足要的需求的領域。
上圖是一段摘自我個人項目的 C 語言代碼（業餘時間寫作，非公司資產），可以看到用到了各種教科書都極力反對的 goto 語句，但實際上，如果是 C 語言比較熟練的話，使用 goto 語句可以大大簡化函數返回時的清理代碼，達到類似 C++ 語言 RAII 的效果。
再舉個例子來說，當你的工作是實現一個被廣泛調用的庫函數，比如 C 語言 malloc 這樣的內存分配函數，那麼，速度和內存使用效率就是就是最大的需求，函數實現可以使用各種醜陋的優化技巧甚至內嵌彙編等等，但只要滿足基本需求，這些破壞基本可讀性原則的手段就不會影響你的代碼成為一段好的代碼。
在滿足需求的前提下，我認為好的代碼還符合以下特徵：
簡單性：能用簡單實現的方法就不要用複雜的方法，越簡單的代碼越容易維護；
可讀性：無論是作者還是他人，都能很容易通過閱讀代碼瞭解到代碼實現的功能，且代碼的編寫沒有違反常理的地方；
分層與模塊化：從架構的層面讓代碼易於理解與修改；
優雅與簡潔：代碼在滿足功能需求的情況下儘量採用成熟的算法與邏輯，舉個例子，計算從 1 加到 100 的總和，優雅簡潔的方法是使用等差數列公式求和而不是用循環累加；
效率：一般來說符合上面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最好
四、學習習慣
1，先學習業務知識，分析業務，對自己的定位是業務領域專家，能快速通曉這個領域大部分的業務知識。
2，業務建模，抽象，能反映這個業務領域的各種變化。
3，只使用JDK進行編程，概念和抽象意義上的編程（算是：瘦核心/領域驅動/微內核模式的開發習慣）。
4，使用JDBC,JMS。。。。等框架，將概念具體功能和擴展落地
大黃哥兒
在我看來，好的代碼分成這幾個層次：
實現功能（需求）
單純的把需求實現，只能算“合格”的代碼，如果要成為（初級）好代碼，我認為還需要做到下面幾點：
代碼的健壯性：需要多考慮規範要求以外的可能，我經常對組員說“不要相信別人，我們要把自己的代碼考慮全面”；比如開發一個接口，雙方已經約定某個字段是必傳的，那麼是相信對方系統會傳這個字段，還是“不要相信對方”，接口中增加非空判斷。
代碼效率：在工作期間，我發現很多開發人員很容易犯的一個錯誤，就是隻關注功能的實現，而不會考慮代碼執行效率；例如測試環境數據庫中有一萬的數據，隨便寫個SQL也不會發生效率問題，但是生產環境一千萬的數據，代碼一上生產就會出現問題（項目最好能提供一個準生產環境，或者生產環境的試運行）。
讓別人能看懂
一方面，軟件開發需要團隊合作，另外一方面，程序員崗位的流動性比較強，可能兩三年過後，項目組成員已經完全換了一撥人了；所以代碼容易閱讀，是很重要的。
遵守代碼規範：代碼分層、起名見名知意、代碼樣式等等；
準確的代碼註釋，接口必須有接口文檔；代碼修改之後，對應的註釋和文檔必須也對應修改；
少些代碼
少些代碼不代表讓你偷懶，要想寫出【好代碼】，一定不能只【看到代碼】。
深入瞭解需求，不合理的需求或者重複的功能，可以拒絕，或者給出其他的建議；
設計和寫代碼的時間投入，一定要合理安排，甚至有些時候，設計的時間翻到更長；
能複用的儘量複用，能抽象的儘量抽象，以便以後可以複用；
如果有經過實際考驗的【輪子】，那就直接拿來使用；
時刻要注意“過猶不及”：千萬不要學了什麼新的技術（框架、設計模式等），一定要用到項目中，而不是考慮是否合理，是否適用。
希望我的回答，能夠幫助到你！我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。
會點代碼的大叔
我是雪鹿，是一名科技領域創作者，希望我的回答可以對你有幫助。
什麼樣的代碼叫好代碼？
我認為要滿足三點要求就可以稱為好代碼。第一是能準確無誤的運行並且實現目標功能。第二就是一個實習生程序員都可以看明白的代碼。第三就是高效明瞭。雖然只有這三點，但是我覺感覺要求還是挺高的。
第一是能準確無誤的運行並且實現目標功能。
一段代碼，不能實現某一個模塊的功能，或者能實現，但是Bug一堆，問題一片，那可能不叫代碼，就是一堆垃圾。更別提是好的代碼了。
第二就是一個實習生程序員都可以看明白的代碼。
實習生程序員都能看懂的代碼，也就是新手都能看懂。這不僅要要求代碼排版合理，還要有關鍵的註釋，以及很好的命名規範。這一點也是非常重要的，尤其對於軟件企業而言，一款軟件絕不是一個程序員可以完成的，符合代碼規範，才能多人高效的協調合作開發完成軟件的開發。如果你寫出的軟件，別人都看不懂，變量的命名甚至還用a,b,c,或者中文的拼音，那就沒啥意思了。
第三就是高效明瞭。
之前我做開發的時候，看過一個工程，功能都挺好的，看了下代碼模塊，發現了一個重複運行10次的程序塊，然後上面就是複製了10遍的代碼塊。簡直爆炸，一個for循環不就可以了嗎。所以程序一定不要看起來像一個沒技術的寫的一樣，有時候申明變量沒有必要就不用申明，直接用現成的，算法結構能很優化，這樣才符合我對好代碼的要求。
最後總結:每個程序員都有自己的代碼風格，但是能保證簡單易讀，是基本要求，寫代碼時加上註釋，日後好維護，與人方便與己方便。
最後說一句，PHP是這個世界上最好的語言（評論區決戰到天亮）
以上是我對這個問題的解答和觀點，純手打，實屬不易，也僅表達個人觀點，希望能給讀者很好的參考，若是覺得寫的還可以就給個贊吧。
雪鹿生活科技
正好，我本身就是一名程序員，在這行裡做了五年了，所以來回答下這個問題。
其實，代碼的價值並不在於代碼本身，而是在於代碼構建出來的產品的價值。一款產品從無到有再到好，離不開代碼的一步步累積！因此，代碼是動態的，是不斷更新迭代的。在這個過程中，面向開發人員的代碼，自然就會被開發人員評判為好代碼和壞代碼之分。
首先，我認為好的代碼要讓人能看得懂它的邏輯和表達意思！代碼是人寫的，也是需要人來不斷維護的，誰都無法保證開發人員就是維護人員，因此，一款產品的代碼，如果每個來接手的人都根本看不明白前面的人寫的是什麼意思，自然而然會影響到產品的更新迭代，甚至會在迭代過程中出現致命的問題。
其次，好的代碼不但要讓人看的懂，還要讓人看的舒服。因此，這就需要技術人員在寫代碼過程中要遵守編程規範，或者是這一套代碼裡體現出來的自己的規範。要保持整套代碼的規範和習慣的一致性。比如：這套代碼裡變量名的命名方式是駝峰法，你就用駝峰法，如果是下劃線全小寫法，你也就用下劃線全小寫法。
第三，好的代碼要簡潔明瞭。具有共性的功能模塊最好進行封裝，不要哪個地方用到，就把所有的邏輯都再寫一遍。同時，要注意MVC架構，處理接受和邏輯儘量放在C層，處理數據的儘量放在M層。
第四，好的代碼要足夠健壯。足夠健壯包含了兩個層面，一個就是上面所提到的儘量簡潔化代碼，要有封裝；還有就是要多考慮情況的場景的複雜性，在代碼中提早最好控制，尤其是針對客戶端輸入的情況，不要相信客戶端的輸入是安全的。
最後，好的代碼，最好是在合適的地方加上合理的註釋，幫助自己和別人快速理解，切不可以為自己寫的就永遠記得，沒有哪個程序員能永遠記得自己寫的代碼是什麼意思，更不要說別人了！
淺談不深究
好代碼這個概念太寬泛了。拋開需求以及架構等我覺得好代碼應該符號這幾個標準。
第一， 符號開發規範。別的開發語言不清楚，Java我還是有發言權的。比如大名鼎鼎的駝峰命名，代碼縮徑，以及每行字符長度等。符號規範的代碼更易閱讀，這樣哪天你換別的項目或跳槽交接起來也方便點。
第二，加合理的註釋。我一直認為註釋是屬於代碼的重要組成。沒有註釋的代碼是很難理解的。尤其是業務複雜的項目，當初你耗費幾周寫出的代碼，如果沒註釋，過一段時間再看也一樣會懵逼。
第三，選用合理的數據結構。對於數據結構沒有絕對的好與壞，只不過是使用場景不同罷了。當然最常用的數據結構也不過是List和Map。
第四，簡單易懂，一份好的代碼應該簡單易懂，而不是為了為了語法而寫。比如你雖然清楚記得運算符的優先級，但是為了可讀性還是要人為加括號。
以上就是我所認為的好的代碼。
但求無Bug
第一，具備可讀性，這就意味著全公司應該有統一的編碼規範和風格，例如：統一的命名規範、統一的註釋要求……
第二，沒有明顯漏洞，不存在安全隱患，業界也有很多漏洞檢查工具，例如：C++領域的coverity……可以快速識別代碼風險和漏洞
第三，可複用和可被複用，包括複用了已有的代碼，以及新寫的代碼未來也可被複用
