怎麼能提高自己代碼的可讀性與重用性？

01-28

現在題主是大二學生，但是期末做課程設計發現很多問題，比如資料庫文件隨便放，不知道導入到項目文件夾下，也不去定義類和方法，代碼直接往事件裡面寫，有很多代碼其實是重複的，這些問題都是在讀一個學長的程序發現自己的不足，想把自己之前寫的代碼用規範做法重構發現也很麻煩，所以現在想了解一下有沒有相關文檔或者書籍介紹這方面的知識，或者怎麼去培養這樣的編程習慣。

書籍：《代碼大全》。

不要被書名嚇到，它的中文名翻譯是一個美麗的錯誤。裡面詳述了編碼的方方面面，當然也包括可讀性和重用性。

就我個人的經驗而言，提高代碼的可讀性，除了恪守嚴謹的編碼規範、遵循良好的命名規約、使用合理的注釋以外，最重要的一點在於，堅持代碼描述思路的原則。即，不管代碼多繁瑣冗長、多雜亂不堪、多性能低下，你只要保證它只做一件事情：嚴格地描述你的思路。只要解決問題的思路明確了，就去實現它，一鼓作氣；不要在編碼完成之前考慮優化和重構，除非你意識到自己思路的嚴重錯誤。就像寫文章一樣，思路走到哪裡，代碼寫到哪裡；思路有段落，代碼里敲個空行；思路有轉折，代碼里可能應該相應地出現注釋；思路被打斷，寫個//todo。

這樣一來，只要保證自己的思路清晰正確，代碼也不會差到哪兒去，閱讀者也可以循著代碼抓住你的思路。

寫代碼時，儘可能地描述你要做什麼（what），儘可能地去隱藏你是怎麼做的（how）。要達到這一目的，常用的方法是封裝。你要打死一隻蚊子，寫一個叫打死蚊子的函數然後調用它，而不是在當前函數里仔細描述你出門買電蚊拍、給電蚊拍充電、滿屋子尋找蚊子、然後將電蚊拍揮向蚊子的過程——閱讀者會被這些細節吸引，然後忘記了你為什麼要打蚊子。人腦的調用棧很淺。

多多利用你的語言和類庫/框架里提供的將你從how解放出來的特性，比如linq表達式。它是.NET Framework 3.5以來我最好的朋友。

接下來才應該考慮重構的事情，也包括你所說的重用性的一部分。實際上，代碼的重用性很大程度上應該是體現在你的思路里的，也就是所謂的架構；但架構能力是需要大量的編碼經驗作為支撐的。完成一個系統或子系統後，問問自己，哪些代碼我應該提取為函數？哪些方法我應該提取為介面/基類/組件？哪些類我應該提取為范型類/模版？哪些代碼我應該獨立成庫？哪些變數/字面量我應該變更為常量？哪些常量/字面量我應該提取為枚舉？哪些實現我可以套用設計模式？這些都是提高代碼可重用性的方式，這時候試著把思考的結果融入你的思路里，對代碼進行重構。久而久之，你在考慮問題時思路里就自帶了這些觀察點，寫出的代碼可重用性也就更高。

最後才是對代碼做性能優化的時候。優化請務必以性能測量（profiling）的結果為依據，只對那些對性能產生關鍵性影響的部分進行。每個優化都可能會不可避免地破壞代碼的可讀性和重用性，一定要用注釋描述清楚。

請牢記先哲的話：

程序寫出來是給人讀的，只是偶爾讓機器去執行一下。
– Abelson and Sussman

做好四點就夠了

正確的分層《Microsoft .NET企業級應用架構設計》 Microsoft .NET企業級應用架構設計 (豆瓣)

面向對象的基本SOLID原則《敏捷軟體開發》敏捷軟體開發 (豆瓣)

恰當的數據結構和演算法《數據結構與演算法分析》數據結構與演算法分析 (豆瓣)

代碼規約

另外重構，整潔代碼，測試驅動開發，企業應用架構模式這幾本都可以看看

提高隊友的水平。。。

我不信一個水平差的程序員能看懂我寫的動態生成表達式樹的代碼。。。

重用代碼的前提是你要先理解你的代碼，理解它們的層次結構。

比如基本的三層架構吧，很早以前我對這個也不懂，每次寫代碼的時候也都是把數據連接、業務處理全部都寫在一個代碼段里。結果發現自己每次都在重寫著很多相同的代碼，比如資料庫連接這一塊的代碼。因為它們的目的都是一樣的，都是連接資料庫，對資料庫進行一些操作，和業務邏輯沒有直接的關係，所以完全可以把這一段代碼給獨立出來。所以後面就自己寫了一個資料庫連接的類庫，它的目的就是："我的目的就是從資料庫讀數據和寫數據，至於其他人要拿這些數據幹嘛，我管不著"。說了這麼多，重點在於先對代碼的理解，而後才是發現這些重複的代碼，把他們提取出來，這樣就實現了代碼的重用性。
至於代碼的可讀性，就在於你對代碼寫注釋了。我剛開始學會編碼的時候，實在不能理解為什麼要給代碼寫注釋，浪費時間，反正是自己寫的還能看不懂么。結果很久以後，想回頭參考以前的代碼的時候，發現自己懵逼了，找了老半天才找到自己想要的代碼，原來自己寫的代碼是真的會忘記的……。現在我已經養成習慣了，不論寫什麼代碼都會寫代碼注釋，雖然不是寫的很細，起碼會對一些功能模塊的代碼和引用某些方法的地方寫上注釋，會發現，一段時間後回頭看代碼，會更容易理解的。

以上純屬個人的觀點，希望對君有所幫助。

寫多了,學多了自然會知道, 一開始你會想到這樣的問題說明你是一個很有心的人. 但是代碼也是要功力的, 沒有人一開始就能寫出非常簡潔的代碼,需要一定的鍛煉和磨練. 或者說吃虧吃多了你自己就會懂.

Atitit. 提升可讀性推薦標準規範解決方案關於編程語言的v5 docx

1. 提升可讀性的意義 1

2. 提升可讀性大原則： 2

2.1. 分解分類層次結構 2

2.2. 命名規範推薦標準 2

2.3. 關注點分離原則 2

2.4. 面向人類編程，優先於面向機器，可讀性優先於性能原則 2

3. 具體措施 2

3.1. （推薦）Dsl **重要 2

3.2. **（推薦）使用漢字命名，獲取更大的可讀性，適合於絕大多數項目利大於弊（推薦） 2

3.3. （推薦）使用命名空間，不支持命名空間的事業類似前綴 3

3.4. （推薦）有時候異常處理也會提升可讀性 3

3.5. （推薦）限制使用spring等框架範圍，防止濫用 3

3.6. （推薦）提高抽象級別，what與how相分離，優先指明what 3

3.7. （推薦）減少架構層次，雙層比三層四層架構更加簡單易讀 3

3.8. （推薦）注意學院派與工程派完全不同 3

3.9. 命名規範參考知名api 3

3.10. （推薦）Sql style api 4

3.11. 適當分層、DI和AOP是繼OO之後的分解方法 4

3.12. 函數式樣流程式控制制全部函數化 4

3.13. 遞歸代替循環 4

3.14. 中綴表達式優先於前後綴表達式 5

3.15. 防止出現大量介面，，介面過多過濫 5

3.16. 減少嵌套級別 5

3.17. （推薦）使用模板法，關注點分離。。字元串拼接太難讀怎麼辦？？ 5

3.18. 減少「語法噪音」 5

3.19. 參考 5

4. Refactor 5

4.1. 方法鏈 5

5. 參考資料 5

1. 提升可讀性的意義

不管對項目還是產品模式，提升可讀性都意義重大。

· 優化可讀性可以讓代碼易於閱讀和調試，從而縮短開發周期，降低開發成本；

優化可讀性——讓代碼更容易閱讀、跟蹤和理解。

在優化時難以兼顧各個方面。例如，當致力於性能優化時，你很可能讓應用程序內存消耗增加，同時代碼可讀性也變差。

2. 提升可讀性大原則：

2.1. 分解分類層次結構

2.2. 命名規範推薦標準

2.3. 關注點分離原則

2.4. 面向人類編程，優先於面向機器，可讀性優先於性能原則

大部分情況下，默認的性能即可滿足要求。。

3. 具體措施

3.1. （推薦）Dsl 重要**

常見的DSL就是h5 sql script腳本。。界面用h5，業務邏輯儘可能用優先使用腳本和sql sp，數據存儲用sql

通用語言GPL儘可能用來縮小使用範圍，用來寫庫是個不錯的使用場景。。。

3.2. **（推薦）使用漢字命名，獲取更大的可讀性，適合於絕大多數項目利大於弊（推薦）

當然喪失了跨國人員合作特性。不過對於大多數都是國內項目來說，就很合適了，根本就沒有外籍人員參與。。

如果發現少部分工具對漢字支持不佳，使用拼音即可。拼音也是拼音文字中文

3.3. （推薦）使用命名空間，不支持命名空間的事業類似前綴

缺點就是命名長度變長了，單是可讀性優先，會提升可讀性，名字長度有ide自動補全緩解。。

3.4. （推薦）有時候異常處理也會提升可讀性

異常處理

3.5. （推薦）限制使用spring等框架範圍，防止濫用

一般他們都會提升複雜度，降低可讀性，應當儘可能的限制其模塊使用範圍

3.6. （推薦）提高抽象級別，what與how相分離，優先指明what

3.7. （推薦）減少架構層次，雙層比三層四層架構更加簡單易讀

當然一些複雜模塊可以使用更多的層數來分解。。

Iso規定有7層網路，實際的tcp只有4層，就是為了降低複雜度。。

3.8. （推薦）注意學院派與工程派完全不同

3.9. 命名規範參考知名api

參考知名api 參考知名sdk 遊戲cocos2d、等..

這樣可以大大減少資料文檔的編撰。。互聯網上已經有了

3.10. （推薦）Sql style api

Sql是個可讀性很好的dsl，對於一些操作以及統計方法，使用sql分格的命名很好理解

private void process(BufferedImage img, int grayLevDeep, int radis) {

new GrayLayerCater().groupByGrayRang(grayLevDeep);

//對模板選框內內的像素顏色對灰度分組聚合分類，分別放在不同的灰度層次裡面

GrayLayerCater1.insertTo_Layers_select_Colors_From(Matrix1).Groupby_GrayRang();

//選擇最多顏色點的那個層次

Layer ColorsNumsTop1Layer = GrayLayerCater1.get_top1_from_Layers_Orderby_ColorsNum_desc();

//計算顏色均值，分別對各個rgb分量計算，與合成

Color avgColor = ColorsNumsTop1Layer.avgColor_retClr();

}

3.11. 適當分層、DI和AOP是繼OO之後的分解方法

3.12. 函數式樣流程式控制制全部函數化

特殊字(如while、class和for)

3.13. 遞歸代替循環

3.14. 中綴表達式優先於前後綴表達式

3.15. 防止出現大量介面，，介面過多過濫

3.16. 減少嵌套級別

3.17. （推薦）使用模板法，關注點分離。。字元串拼接太難讀怎麼辦？？

var sql=" insert `常用洗衣網點`(工號,網點名稱)value("@uid@","@add@")";

sql=sql.replace("@uid@","123");

sql=sql.replace("@add@","實際地址");

alert(sql);

3.18. 減少「語法噪音」

3.19. 參考

4. Refactor

4.1. 方法鏈

5. 參考資料

Atitit.提升語言可讀性原理與實踐

Atitit usrQBF2312 命名空間pkg 以及 api命名 spec規範

如何提高代碼可讀性 - GC2013 - 博客園.html

如何提高代碼可讀性、可維護性 - zm1_1zm - 博客頻道 - CSDN.NET.html

作者:: 綽號:老哇的爪子claw of Eagle 偶像破壞者Iconoclast image-smasher

捕鳥王"Bird Catcher 王中之王King of Kings 虔誠者Pious 宗教信仰捍衛者 Defender of the Faith. 卡拉卡拉紅斗篷 Caracalla red cloak

簡稱：： Emir Attilax Akbar 埃米爾阿提拉克斯阿克巴

全名：：Emir Attilax Akbar bin Mahmud bin attila bin Solomon Al Rapanui

埃米爾阿提拉克斯阿克巴本馬哈茂德本阿提拉本所羅門阿爾拉帕努伊

常用名：艾提拉（艾龍）， EMAIL:[email protected]

轉載請註明來源：attilax的專欄 http://blog.csdn.net/attilax

--Atiend

[?1P[?1??