薛小落
通常來說，在任何一個項目組中都應該有各自的編碼規範，目的就是為了增加代碼的可讀性和可維護性，那麼，到底該如何做呢？
1/7 分步閱讀
變量命名要有意義，最好是使用英文命名，實在不行的，使用拼音。除了循環中的計數變量，以及特殊場景之外，任何變量都儘量不要使用a、b、c這類完全沒有任何意義的名稱。增強可讀性
2/7
變量除了要有意義之外，還需要統一大小寫，比如第一個單詞首字母小寫，後續單詞首字母大寫的命名風格。風格統一後，看著代碼都會心情舒暢一些，從而可讀性更好
3/7
添加必要的註釋，雖然，某些變量名可以看出意義，但是，必要的註釋可以更為直觀的讓人看懂代碼，增強可讀性
4/7
增加代碼段的註釋。如果是C#語言，可以使用region語法包裹一段邏輯，到時候摺疊起來，看起來整體性就很容易閱讀。其他語言可以使用比較明顯的分隔符號標明段落
5/7
將很長的函數拆分成較小的函數，這樣不僅可以增加代碼的可讀性，還能增加代碼的可維護性
6/7
將代碼劃分層次，比如，訪問數據庫的代碼單獨放在一個項目中，前臺代碼單獨放一個項目中，到時候修改的時候就很明確，不至於四處亂找，增加可維護性
7/7
代碼的層次之間通過接口來調用，減少各個層次之間的耦合度，增加可維護性
科技許
根據個人多年代碼經驗：為提高代碼的可維護性，首先 1.在項目工程搭建時候，包命名規範，功能模塊儘量獨立結偶，劃分不同服務2.項目代碼基本規範插件和項目組代碼規範要求文檔（本地安裝阿里掃描插件掃描，代碼圈複雜度掃描，重複代碼重複檢測，代碼安全covert er 掃描）3.代碼設計模式靈活運用，代碼常量，枚舉類，公共方法類定義，切記不能使用魔鬼數字 4.對於業務複雜的流程，寫好必要註釋，同時最好配合流程圖文檔說明
5.項目組定期舉行代碼走查，代碼分享會
以上僅個人皮毛經驗，還願與您互相交流探討！
碼農三哥
為了提高代碼的可維護性，我根據自己的實際情況總結出以下六點方式，供您進行參考。
註釋您的代碼
/*
註釋你的代碼至關重要，因為如果您編寫了一個程序卻未對其進行註釋，那麼缺少註釋將使您浪費時間來重新寫一遍代碼。畢竟基本上就算是你自己寫的代碼，幾個月不看那肯定就忘了。所以註釋代碼又幫助了別人也幫助了你自己。當然如何註釋好代碼又是一門學問了，這裡就不扯遠了。
*/
不要忘記錯誤檢查
每個中型程序都有很多功能和過程，這意味著每個程序都應進行錯誤檢查。良好的錯誤檢查可以防止程序BOOM了，並使調試速度更快。當然現在優秀的IDE都自帶查錯功能，你現在基本不必花費很多時間查找錯誤。
使用更少的代碼
這是有道理的，你有更少的代碼，這樣也變相的提高了可維護性（誰會想維護一個用了幾百上千的ifelse語句的神仙代碼）。它擺脫了未經修改的功能和診斷語句將使您的代碼看起來更簡潔。如果您有機會使用現有的庫，那就更好了！這樣會一定程度的提高可維護性，畢竟這會精簡你的代碼。
編寫易於修改的代碼
這也可以說成是編寫模塊化的代碼，這即方便移植也方便別人來修改你的代碼，但是當很多人都使用了你編寫的代碼，但是在使用過程中發現它出問題了！這時候如果只需要改幾個define的參數的話就能修正就能減少很多工作量，不然就需要每個人都重新更改他們的代碼，增加了很多工作量。
編寫易於測試的代碼
發現錯誤越早，修復該錯誤的成本就越低。儘管測試每種可能的情況都可能很耗時，但是你可以編寫一段簡短的專用於測試的代碼，這雖然看上去是多餘的，但真出了問題這可就是防範於未然了。
解決問題，而不是症狀
這也是很多程序員偷懶導致的更多的問題
快速修復和實際修復之間的區別是，第一種情況是開發人員決定解決症狀而不是解決問題時發生的。當開發人員細緻的瞭解錯誤原因並設法查明錯誤原因時，才可能進行真正的修復。倉促完成的所有操作只會創建令人困惑的代碼，供下一個倒黴的人清理。
有些人剛進公司，看到上一個人留下的“遺產”，那絕對是崩潰的。
以上就是個人認為的對編寫可維護性高的代碼的一些方法，如果還有其他疑問的話可以在評論中提出，謝謝！
天均地鞭
1.多寫有效的註釋。注意是有效，不然寫再多也沒用？像大家都懂的可以不用寫，關鍵的地方一定要寫。
2.持續重構。一定要不斷地重構，一有空的時候，見縫插針，最關鍵的一點是發現兩個地方代碼相同的時候馬上重構抽取，這個習慣養好了就事半功倍了。
3.注意格式。有的人寫代碼歪歪斜斜的，沒有分段或者格式化，層次結構很不清晰，各種跳轉代碼。其實代碼塊最好都是按順序下來的，按生命週期等方式，每個類的初始化，設置參數，設置監聽，銷燬等都按一定的順序寫下來，整個邏輯清晰很多。
4.獨立模塊。當各種類獨立後還要考慮獨立模塊，模塊化開發的好處顯而易見。比如我單獨引入百度地圖模塊，可以多個項目複用，自己的模塊也是一樣。
5.設計模式。如果能力較強，在適當的地方使用設計模式，使代碼解耦的更好。
