陶佳奧
作為一個已經寫了十幾年代碼的程序員，做好軟件不是全部圍繞代碼而展開，換句話講一個程序員的程序員優秀不僅僅體現在代碼上，更要有內在的編程思想說的層次再高深點就是框架思想。很多初學者都會存在很多疑問，覺得能夠寫代碼就萬事大吉了，在能寫代碼之前會有很多疑問
數學不好能學好編程不？
英語不好能不能學好編程？
這些都是還沒入門的疑問，真正入門之後發現這些都不是什麼問題，真正決定程序員水平也不是簡單的能寫多少代碼，真正項目實施過程寫代碼的時間佔據不到百分三十，大部分時間是在設計和構思上，當然佔據時間最多的是調試以及客戶後續提出的需求上面，現在很多人還在糾結是不是要多學習幾種編程語言，編程語言本質來講就是一種工具，主要指導思想還是編程思想。
現實中如何才能寫出高質量的代碼？
1.良好編程基本功。再高的大廈也得需要強大的編程基礎，不一定要掌握多少種編程語言關鍵要非常熟悉一種編程語言，裡裡外外都給吃透了，達到這種程度至於掌握幾種編程語言就顯得不是那麼重要了，到了這種程度就可以觸類旁通，切換一種新的編程語言也不會費多大事，有事沒事就回頭看看基礎書，越是編程高手越是注重基本功的學習，很多做java的程序員，java編程思想這本書看了不下十幾遍，而且還在繼續，基礎的學習什麼時候值得回味。
2.專業知識的雄厚。編程語言只是工具，工具如何才能使用好，還是要看這工具是用來做什麼的,比如安全領域可能使用C語言或者C++編程，如果安全專業知識掌握的非常紮實，工具使用起來再更加熟練，才能有高質量的代碼出現，要把一個事情做到極致，各個細節點就要落實到位，缺一不可。
3.好的軟件框架，軟件框架是寫出高質量代碼的土壤，假如一個能力很強的人，進入一個亂糟糟的公司基本很難發揮出最大的潛能，所以生存土壤很重要，一個優秀的產品一定是代碼各個模塊有機配合在一起共同做出來的，一個模塊的優秀代碼優秀，整個產品出問題了意義也不是很大。
4.高質量的代碼從來都不是一次性搞定的，都是經過多次的打磨修改出來的，玩過開源的人應該都明白，代碼模塊不停的升級優化折騰不停，不僅僅是功能的增加更重要的代碼質量的提煉，所以想寫出高質量代碼需要敢對自己下手，對自己要狠一點才能有高質量的代碼出來，細心的人可以觀察下身邊優秀的程序員，看看是不是都是這麼做的。
做到以上四點，堅持下去寫出來的代碼質量不會差，當然還要懂得去閱讀別人寫的優秀代碼，開始看的時候不一定能看得懂，不能大塊的看懂就切塊去看去學習，以前有個linux內核愛好者，整體看linux內核代碼，有一天看到他十分開心的樣子，問發生了什麼事情，說看懂了linux內核裡面的內存是如何管理的了，然後拉著我給我講了半天，雖然沒聽懂但也堅持聽到最後，畢竟代碼能寫的前提是能看懂，所以開源社區的代碼如果能看懂就是一個非常大的進步，然後一步步的掌握起來，格局放大一定做出更大的事情來。
大學生編程指南
我認為高質量的代碼有幾個特性：
實現目標（需求）
這是評價代碼的前提吧，這一點要是沒達標，代碼肯定是不合格的。
代碼規範
好的代碼一定有良好的代碼規範，包括代碼分層、各種命名、代碼風格等等。這麼說吧，就算是一個不懂代碼的人，看到有良好代碼規範的代碼，也會覺得賞心悅目；而對於專業的人來說，良好的代碼規範會提高代碼的可讀性。
代碼複用
避免代碼重複，最常見的問題就是方法不復用；代碼重複率也是考核代碼質量的一個重要標準。
健壯性和可擴展性
提高代碼的容錯能力，需要在編碼過程中，儘可能提前考慮到所有的情況。
易於擴展：業務在變，我們的代碼在變，如果一個業務流程寫在一個方法裡面，那麼真的會三天一小改，五天一大改。
單元測試覆蓋率
估計很多人寫的代碼都缺少單元測試用例，有些程序員也很排斥寫單元測試用例。個人認為，單元測試用例可以在很大程度上避免：修改了一個BUG，又造成十個BUG的問題。(不要影響到正常代碼的運行)
代碼的學習過程，就是看代碼-模仿著寫代碼-自己寫代碼，要想寫出高質量的代碼，不外乎就是：多看、多寫、多思考。
多看
買幾本經典的編程書籍，按照上面的例子敲一遍，再跟自己寫的代碼比較比較，看看是否有差距。如果初學者的話，不建議上來就看開源框架的源碼，火候還沒有到那個水平，理解起來比較困難。
多寫
養成良好的編程習慣，可以學習一些大廠的代碼規範；儘可能減少重複的代碼，可以把可重用的代碼，抽象出來；適當的進行重構，好的代碼不是一次就寫成的；合理使用工具，善於使用工具。
多思考
對比別人優秀的代碼，想想人家寫這段代碼時候的思路是什麼樣的；看到別人的“爛”代碼，也想想自己是否犯過這樣的錯誤；代碼編寫過程中，多想想有沒有其他的情況發生，以後萬一要是需要擴展，現在的代碼是不是需要留下什麼“口子”方便以後擴展。
編程能力的提升，是一個長久的學習過程，希望大家都能寫出漂亮的代碼。
會點代碼的大叔
有一些基本的原則：
1、可讀性：代碼是寫給人看的，一定要考慮以後接手這段代碼的人的感受。函數名，變量名，類名等最好做到顧名思義，一看到名字就能猜到它是幹什麼的。一些關鍵函數要加上註釋，但切忌給每個函數都加註釋；
2、函數的代碼儘可能短：儘量避免很長很大的函數，體積龐大的函數通常說明你在函數里做了太多事，應該將他們拆分成一些更小的函數，這樣帶來的好處是複用性的提高；
3、避免過多的函數參數：通常一個函數的參數保持在3個以內，尤其是對外提供的接口，參數太多會讓使用者感到不舒服，也違背了接口易用性原則；
4、避免萬能類：遵循面相對象中單一職責這個原則，不要在一個類裡做太多事情，這樣的萬能類毫無複用性可言，而且對後續維護者來說絕對是巨坑。我是做安卓開發的，曾接受過的項目裡有一個activity，代碼超過了1萬多行，簡直淚崩；
5、對你的代碼分層：不要一上來就擼，要先對項目中的功能進行區分，然後用mvc，mvp或者mvvm等進行分層；
6、靈活運用設計模式：代碼擼多了，項目做多了會發現設計模式會非常有用，比如曾經參與過騰訊某直播app的項目，其中直播間的功能非常複雜，不斷有產品需求向直播間加功能，最後用decorator模式很好的解決了直播間擴展性問題，每當產品要給直播間加個功能就這一個decorator就可以了，其他代碼基本不用大改。
當然還有很多要注意的點，這裡就不展開說了。總之就是自己多擼，然後光擼還不行，多看看優秀的開源項目的源碼，看看優秀程序員的代碼，日積月累自然就能擼出優美的代碼了，加油，騷年！
區塊鏈接未來
好的代碼本身就是最好的說明文檔——Steve McConnell
在w3cschool以往的回答中，曾經這樣形容高質量的代碼：
“好的代碼，就像是小說家手中的短篇小說，邏輯清晰，簡單明瞭，卻又能觸動心靈，而壞代碼，就像是一輛外表富麗的老舊汽車，開不動不說，隨時還有散架的危險。”
如何判斷程序員寫出來的代碼的質量的高低是一個頗具爭議的話題，每個人的理解可能都不一樣，所以制定一個符合自己部門要求的規範，有了依據，寫出來的代碼才有可能成為好代碼。
好代碼的判斷標準
可讀性
就像開頭引用中所說的，好的代碼本身就是最好的說明文檔。
代碼幾千行，所有業務邏輯全部揉在一起，除了你沒人看得懂，週末想續寫代碼，結果發現連自己也要看半天，才能接著寫下去，這樣的代碼，能是一個好代碼嗎？
判斷：將代碼拿給其他程序員看，在讀代碼期間，他向你提出的問題越少，說明這些代碼的可讀性也就越強。
要想讓部門所有人寫出的代碼可讀性強，就必須制定一個統一的開發風格，這樣不管是老程序員還是新程序員，都能快速上手，可讀性也會得到一定的保障。
可維護性
曾經看過一段代碼，一個method幾千行代碼，沒有人敢維護，修改一點點就會發生不可知的錯誤，代碼又臭又長，除了重構，完全沒有辦法。這樣的代碼，就是一個差到不行的代碼。
判斷：一般有三點可以做個大概的判斷，一是易讀，二是可拓展，三是數據靈活，四是可追蹤。
簡潔性
很多程序員之所以喜歡寫長代碼，主要是寫起來沒什麼障礙，也不用怎麼思考，跟記流水賬一樣。還有就是學習的時候，養成了一些不良的編程習慣，亦或是習慣成自然，已經不知道自己所寫的代碼，是不是夠簡潔了。
判斷：拿出以前寫過的代碼，讀一下，看看是不是簡潔了，如果是，至少說明你現在寫的代碼，比以前簡潔了。
模塊化
好的代碼，都是模塊化的。假設你的項目有三個不同的層，分別為內層、中層和外層。你的內容不應該從中層和外層那裡導入任何東西。中層不應該從外層導入任何東西，這樣做的好處是，你可以對代碼的內層進行獨立測試。
W3Cschool
先從類名、函數名、變量名等有含義開始。要儘量做到代碼結構化、模塊化，即一個函數就做一件事情，一件事情就專門的一個函數，函數內的代碼都是為了執行這件事的代碼，而沒有其它，函數的參數和返回類型要想好。這樣，可實現其它多處都可調用此函數。若每個函數都做到了這點，不光可讀性提高了，也提高了代碼複用率。代碼複用率提高了，你的開發效率就提高了！可讀性好，發現BUG就可快速定義！結構化、模塊化、代碼複用率高、可讀性好，則擴展性強，再加上發現BUG能快速定位，結果你的工作效率比別人高得多！加班？不存在的！除非完全是需求改動太頻繁、公司的任務工期安排不合理。
小鳥慢慢飛
既然這麼問，看來你需要判斷好代碼的簡單標準(至少知道哪些坑萬萬不要踩到)：
第一標準----好不好改。要好改，先要好閱讀。
-
第二標準---邏輯好不好捋。
第三標準---功能好不好擴展。
讓代碼容易閱讀的基本習慣
要好改，看懂函數名稱、變量名稱是第一步，所以，你需要注意命名的雷區。
- 函數名稱、變量名稱、class名稱、id名稱要見名知意，就不用說了。你一看到它，就要能大概知道它是用來幹什麼的。
函數名稱、變量名稱全用小寫字母的話，要用下劃線分開，例如get_order，不要寫成getorder，不然單詞邊界難以辨認，甚至容易誤解，讓人火大。特別是：像“getorder”，容易看成ge/torder，而不是“get/order”；像“isfocus”,還稍微容易正確理解為“is/foucus”。自帶函數就算了。全用大寫字母的話，與此同理。允許編輯器檢測單詞拼寫，它認為拼寫錯誤，顯示了下滑曲線，你就修改，有助於避免/很多人在犯的/這種壞習慣。
英語不好的話，請使用翻譯程序。英語單詞看不懂還有地方搜索。千萬不要使用拼音命名函數名稱、變量名稱，不然極難看懂，還沒地方搜索，只能詢問。尤其是拼音首字母拼湊，完全看不懂，跟天書似的，我寧可你使用漢字，函數名、變量名使用漢字又不是一定不支持。使用漢字不丟臉，真的，你的名稱好理解，別人還要謝謝你。
代碼，代碼，代碼，自然是要碼得整整齊齊。養不成這個習慣? 試試玩一玩python。
容易捋清邏輯的基本習慣
新手寫代碼，判斷一多就容易層層嵌套，那麼多if-（elseif-）else看起來就很龐雜。改一改，能平行，就不嵌套。具體來說，就是處理邏輯少的判斷先寫，不符合要求的話，就不能往下運行。你可以先畫畫流程圖，先捋一捋邏輯，wps2019可以幫你的忙。
elseif/else旁邊只能有一個大括號，我建議，elseif/else獨佔一行，不然，摺疊較長的代碼之後，多個elseif排成一行，很難概覽邏輯分支。
下文的W3cschool建議一個method/function不要太長，一行代碼也不要太長，在下深深贊同。我寫的代碼，偏向於拆成多塊，放在不同的method/function中。我還建議你，一個文件，代碼加上空行、註釋塊等，最多2000行左右。不要一個文件長達8000行、甚至20000行，不然就成了“千人排，萬人坑”。
- 邏輯要容易捋清，肯定要模塊化。模塊化是戰略，面向對象是戰術。你先試試面向對象開發程序。我當年第一次面向對象開發php程序，太爽快了，玩法豐富，再也不要面向過程了。
更容易擴展的小建議
一個函數的參數，3個不夠，5個還是能忍的。需要更多參數的話，就整合參數：像function myFunc(a,b,c,d,e,f,g,h){}; 改成function myFunc(config){}; 就好很多了，要是日後需要傳入額外的數據，或者傳入的數據的個數有變動，也更不容易“牽一髮而動全身”。
php程序員飛飛小壞蛋
多看優秀項目代碼
多親自動手寫
多反思回顧自己寫過的代碼
互相多review code
保持謙虛開放的心態 在別人說你代碼不好時
我是沙漠的沙
高質量的代碼在完成需求的基礎上，可讀性永遠是排在第一位的。這就是為什麼要有高級語言的一大原因。可讀性也就以為著可維護性。如何能做到可讀性，就需要代碼人員時時刻刻想著讀你代碼的人會怎麼理解，讀你代碼的人未必是別人，也很可能是將來的你。如何把自己的思路用代碼描述清楚是關鍵。好的代碼通常能夠做到自描述，不用寫註釋也能讓別人看懂，變量名函數名很說明問題了，只有當確實比較難懂，或者易混淆的地方才加入必要的註釋。寫代碼基本原則松耦合低內聚，說來簡單，能做好的不多。好好體會這6個字就能寫出不錯的代碼。
zhangyiant
當然最簡單的一種方法就是多寫，空閒的時候多看看優秀的代碼是怎麼寫的？多學習一些算法是如何運作的？模仿優秀的代碼的寫法可以在短時間內快速提升你的代碼質量。
希望我的回答能夠幫到你。
劉金玉編程
要寫好代碼首先需要有好有結構化思維
