良好的編程習慣有哪些？

01-05

經常在IT行業的實習招聘上看到要求「良好的編程習慣」，這是一種怎樣的習慣呢？

首先，無論如何都要在任何代碼中堅持Don"t Repeat Yourself。

良好的編程習慣有很多方面：設計、ReadMe、編碼風格（命名見名知意、合理的注釋）、單元測試、CodeReview等等；

也有很多方法和方式來改善編程的質量：比如TDD、防禦式編程、設計模式；

對於提高編程質量也有很多值得一看的書，比如《代碼大全》、《代碼整潔之道》、《高質量C_C++編程指南》。

在這裡推薦幾本對我編程生涯影響較大的書，僅供參考（建議先看書評）：

代碼大全（第2版） (豆瓣)

高質量程序設計指南 (豆瓣)

另外個人認為這種編碼風格很贊，推薦閱讀：

Trinea/android-common · GitHub

匿了吧，但都是肺腑之言。

妹子是文科大學的計算機專業畢業，讀書的時候對編程沒什麼感覺，也不怎麼懂。畢業後機緣巧合進了世界top3的投行做軟體開發（各種機緣巧合）。我用的是java，這一年對編程學到的比過去5年學到的都多。

（1）Test Driven是很重要的！！！我不能強調更多它的重要性，特別是在投行這樣的地方，代碼的安全性是最基本最重要的要求。更重要的是，Test 覆蓋得很全面的代碼是很好維護的，我們有60%以上的時間在寫Test case, 40%甚至更少在寫邏輯，雖然開始貌似慢，長期卻是非常節省時間和精力的。我們要達到的境界是，無論改哪一行的代碼，都會有Test case 掛掉；只要Test都過了，怎麼改代碼都可以。這個境界或許要在工作中才會深有體會，是很美的境界！（是啊，我知道作為妹子這麼geek是很無恥的）

（2）編程序最難的是對原則性的東西都很強烈的「感覺」。因為這就像建造一座房子一樣，空間怎麼分布，怎麼設計能達到最優的結果，自己得有大局觀。比如interface不是隨便寫的，如果你寫一個interface是煮速食麵，參數是一袋速食麵，那你不能在interface上暴露出來是電飯煲煮速食麵還是電磁爐煮速食麵，這個是內部實現，這個類的用戶只關心把速食麵煮熟，不關心怎麼煮。這個學名叫類的封裝。編程裡面有好些這樣的原則，比如single responsibility, Open-Close, blabla, (SOLID, four principles). 我面試那會兒這些很熱門，但真正理解，那都是工作之後。

（3）所謂的繼承也好，多態性也好，各種generalization，那都是很學術的，在實際應用中，寫出的代碼解決眼前的問題最重要。不要一開始就太有野心，想著怎麼重用，怎麼寫interface，不要把簡單東西複雜化。其實真的普遍要用的東西，Java的library,以及各種其它的library里都寫好了，你自己費心寫出來的那些期盼著以後有別的用處的功能最後都是沒那麼實用的。

（4）接著上面說，好的代碼都是非常好懂的，簡潔明了。同事告訴我，如果你看到很彆扭的代碼，只能說明寫得很垃圾。

（5）編程永遠都會遇到不懂的知識，要好學，善於學習，我基本是不會記得很多函數的具體用途的，但我會google啊！stackoverflow就跟編程的百度問答似的，什麼答案都有。勤問問題，多思考，多總結，不要犯同樣的錯誤。

（6）不知道這個算不算編程習慣，但對於一個developer，特別是好的developer，要溝通能力特別好（我知道有人會說編程嘛，會寫就行了，不用嘴皮子。但妹子在這裡說的是，好的developer! ）我的同事算是世界上最優秀的那一批人，編程對他們來說只是邏輯表達的工具，而不是目的。其實編程和寫作，作曲，戲劇表演有共通之處，只是一個媒介。它所傳遞的，是商業世界運作的邏輯。一個好的developer，他一定是對他所表達的領域有著精深的了解的，同時，他一定有著很強的表達能力，無論是口頭還是筆端，這樣他才可能了解client的需求，才能和teammates很好地溝通合作。

（7）最後，哎，我真的不想看上去這麼女漢子，但還是忍不住說。現在學計算機最好找工作，為什麼？因為把邏輯寫入機器代替人力勞動，是人類生產力發展的需求。我們很多的trader都失業了，因為很多的交易現在都是用軟體自動生成，創造的利潤比人操作更高。只要是有嚴謹邏輯，非創造性的活動，都可以靠代碼完成。我想，比起培養良好的編程習慣，更重要的，是要熱愛這個行業，認識到它的意義，價值，和無可限量的可能性。這將是一個更好的世界，因為我們都可以從不必要的腦力勞動中解脫出來，有更多的時間進行寫作，拍電影，刷知乎這樣有意思的，創造性的活動中！

（8）最後的最後，我很不喜歡叫自己程序員，顯得跟沒腦子似的。我喜歡我同事的說法：「programmer is the lowest level, we normally call ourselves developers, because we are creating software. But eventually, our goal is to be a problem solver.」

當你把自己當作一個problem solver的時候，你會發現，這已經是一個不一樣的世界。

1.看《代碼大全》

2.看看google 編程規範。

1.DRY

2.代碼風格統一，排版優美

3.合理注釋

4.寫代碼過程持續重構保證代碼質量

5.不保留注釋掉的代碼

結論：個人認為比較好的編程習慣之一是「模塊化」。

背景聲明：

我不是Coder，而是Programmer，非面向底層，非職業碼農，只是將編程當成分析問題與解決問題的工具，因此我的意見未必具有普適性。

我常用的編程語言是C++、SAS、Matlab，其中C++用於行情軟體二次開發，只是使用C++調用數據介面並將目標邏輯程序化後返回結果；SAS用於大數據分析，一般是處理股價數據，搞個股票網路分析、量化投機組合及回測之類的；Matlab一般就用來畫圖，因為這個軟體計算效率太低，處理大數據會死，不過優點是處理小數據時比較全能。

所謂「模塊化」其實未必要搞得多高深，重在把握模塊化的邏輯。我個人在小型編程中的體會是將演算法按照邏輯架構拆分，並將常用函數統一放入函數庫。要使每個程序模塊彼此獨立，而彼此間僅用一兩個數據頁進行數據傳遞，這樣以後檢查與修改時，把輸入一鎖，然後只改模塊即可，並通過輸出來判斷改進結果。我不喜歡Matlab的另一原因是它似乎只能一個個自定義函數，不能在同一M文件內設置多個函數；而C++可以自定義頭文件，SAS可以自建宏程序庫，就非常方便。

下圖是一個SAS程序作業的案例，先是運行一個統一預處理模塊，然後按作業的邏輯順序運行不同模塊。由於運行時間較長，設置了一個計時器，一個執行完成後的報警器。比如要測試一個大程序，可以點完運行先在一旁休息，等報警器響起來了再看，然後根據計時器查看每個模塊的耗時，決定是否需要進一步優化。

The Practice of Programming

Brian W. Kernighan 和 Rob Pike 著

不要讓隊友維護你的代碼時，有砸電腦的衝動。如果做到這一點，你的編程習慣至少不差。

碼農一枚，知乎大牛很多，不敢班門弄斧，只是說說作為碼農的一些看法。從最初的C語言，到VB，再到C#，最後是Ruby，每種語言都有自己的風格。學C語言的時候用的機器印象中是586，黑白顯示器，沒有滑鼠，敲出來的代碼在黑白顯示器上的"可讀性"很差，對於初學者的興趣簡直就是毀滅性的打擊，可想而知，我的C語言沒學好，我說這個並不是給我的C語言沒學好找借口，我是想說，代碼不單是寫給機器的，也是寫給人看的。

既然代碼寫出來是給人看的，那顯然可讀性很重要了。這樣就形成了語言的編程風格，這編程風格不就是為了讓大家養成良好的編程習慣。不管什麼語言，編程風格可能不同的，但有些習慣是共通的。本人寫web方面寫的比較多，就以web方便的編程舉例來說。

一、程序文檔結構方面的習慣

1、文件結構

就拿寫一個小型網站項目來說，養成良好的文檔結構分類習慣是很需要的。如下圖

我把解決方案分成了8個項目，按各自功能劃分，這樣就比較清晰了。在Web子項目里可以再分，分成JS、CSS、Images等。

2、代碼結構

這個我只說下代碼的層次結構，為了方便閱讀，盡量把代碼的層次結構把握好，一段代碼里有好幾層，有判斷，有循環等等，該縮進的縮進，盡量避免大量使用循環嵌套和條件嵌套。

二、編程方面的習慣

1、命名習慣

這個命令習慣包含文檔的命名，對象變數的命令，如當類型命名為Product時，其源文件也命名為Product.cs.可讀性好的命名如：

用戶類型命名為UserType，不要命名為type.

訂單信息命名為OrderInfo，不要命名為Order.

2、注釋習慣

良好的命名已經可讀性加了一半以上的分，再加上良好的注釋習慣，就非常OK了。

三、編程字體選擇

個人對編程字體的要求是比較苛刻的，本人經常用編程字體有：Consolas、Andale Mono、Monaco、Droid Sans Mono、 Deja Vu Sans Mono

以上只是個人見解，歡迎拍磚。。。

bug再多也不能砸鍵盤，更不能砸電腦

寫的代碼別人一看就懂

記得寫修改日期啊

讀10個不同水平同學的代碼，水平之外，最讓你頭疼的，也是最應該規範的。

儘可能少用全局變數

這句話一般指source control, document, coding standard這類東西。

建議，看看代碼大全，讀完了，就知道。

如果簡單點。

1。良好的程序結構

2。良好的程序注釋