編程中有哪些從一開始就值得堅持的好習慣？

歡迎關注公衆號：計算機視覺life，學習切忌單打獨鬥，這裏有教程資料、練習做業、答疑解惑等，優質學習圈幫你少走彎路，快速入門！

本文來自知乎上的同名問題，本文對優秀的回答進行了整理，解釋權歸答主全部，若有侵權請聯繫刪除。

請你們各抒己見，爲初學者提供參考。感謝各位。

---

Yul8ulY：

重視模塊化，重視抽象但不濫用
我剛接觸編程的時候，在網上看到許多大牛寫程序都十分注重模塊化，所以我就下意識的模仿他們；後來看SICP，知道了抽象的好處，所以在寫程序的時候會仔細思考抽象的問題。這些對我都有着很是大的幫助。
在一篇講述程序員代碼行數瓶頸的博客中（程序員的成長和代碼行數的關係）提到，程序員在2k行、20k行、200k行等若干程序規模時會遇到瓶頸，若是不用更科學有效的方法，超過了這個行數代碼就會混亂到難以維護。但我第一次寫很大的程序時（8k+）並無感受到文中提到的瓶頸；我目前接手的項目有近900k行，我本身寫的部分也已經快上10k，但我仍然沒遇到文中提到的瓶頸。
針對這一現象，我作過一些實驗。我在很不認真的寫一些小程序時，也老是寫的混亂不堪，我發現，這種狀況下，程序行數超過200行我就覺的很難受了，在須要進行一點小的修改時，我每每須要花很長時間去尋找到底該改哪裏，十分吃力——這種吃力感是我在那些精心思考的大項目裏從未感覺過的。這說明了，我並無過人的天賦能在混亂中輕易找出清晰的脈絡，那就是說，以前的如魚得水，是由於好的習慣。
後來，我進行了深刻的思考。在模塊劃分合理、抽象合理的程序裏，我能夠簡單的把一個個功能抽象爲一個簡單的黑盒，我不須要知道他們內部發生了什麼複雜的反應，我只須要知道他們對什麼樣的輸入會作出什麼樣的輸出。這種抽象極大的減輕了大腦的負擔，讓我能夠把精力更多的投入到真正須要考慮的地方。而那些混亂的程序裏，我須要理清每一句話之間的關係，這無疑會極大的消耗腦力。這種狀況下，200行就渾身難受就能夠理解了——由於我用於維護項目關係所消耗的腦力已經遠遠大於了那些好程序裏的消耗。
這個習慣，真的讓人十分受益，請必定堅持。剛開始的時候，你或許以爲花很長時間去思考程序的模塊劃分、抽象層級是十分浪費時間的無用功；但久了之後，你就會感覺到這種習慣帶來的好處：它會在無聲無息之間幫你消除掉許多瓶頸。並且還有額外的好處：當你習慣用模塊
化組織你的思惟時，思惟能力也會有必定的加強。

李濟深：

哈，這真是一個有意思的問題。
一些朋友說的好比儘早習慣作版本管理，一開始就造成良好的代碼風格，我很贊同，另一些朋友提到DRY原則，大括號對齊，甚至還有free(p);p=NULL;這樣的建議，都是很容易誤導人的，這裏但願剛入門或者入門不久的朋友們學會獨立思考，凡事打個問號，不要盲目遵循。
我我的以爲最重要的一個習慣其實有不止一我的說了，就是想清楚以後再動手。這裏我稍微展開說一下，由於「想清楚」實際上是一個很模糊的概念。怎樣纔算想清楚了呢？
我經常有這樣的經歷，對一個難題，通過了一番思考以後以爲本身想到了一個比其餘人好得多的方法，結果去實現的時候，發現原來是想的時候疏漏的一個細節，方法不可行，感到很挫敗，不得不回頭過去從新審視問題，浪費了不少時間。
怎樣才能想清楚呢？
Leslie Lamport在斯坦福作了一個講座（底下有連接，推薦）。裏面引用了一句話：「Writing is nature‘s way of let you know how sloppy your thinking is」 我深有同感。怎麼才能知道本身是否想清楚了呢？最天然的方式就是寫下來。怎麼寫呢？這個因人而異，好比我在編碼以前，會在以下兩個問題裏面迭代幾回。

0. 作什麼？（需求：白話）
1. 怎麼作？（方法：僞碼）
   關於作什麼，其實就是分析需求，這裏跟那個「需求分析」過程有些區別。怎麼舒服怎麼來，大白話，不拘一格，理清楚問題就行。我一般的作法就是以自言自語自我審問的方式把整個過程理出來，爲了避免至於特別無聊，這部分一般會寫得十分口語化。等這部分弄清楚以後，基本上僞代碼的框架在內心面就有眉目了。接下來會嘗試着寫僞代碼，寫僞代碼的途中一般會不斷的進行重構或者跟第一步進行迭代，直到僞代碼比較精簡，邏輯上沒有冗餘的時候，就去喝杯咖啡，小個便，回來開始實現。實現的過程當中不免會有須要回到第一個步或者第二步進行迭代的時候，隨着經驗的提高，迭代的次數會變得愈來愈少。
   實際上0,1兩步我都是在代碼的頭部大塊註釋裏面完成的，這個部分能夠直接成爲十分容易理解的文檔。實際中除了這塊註釋，我幾乎不在代碼裏面寫註釋。除了少數實現的trick外。
   另外剛纔提到寫僞代碼，引出了一個潛在的問題：怎麼寫僞代碼？建議不要嘗試着用算法導論或者一些論文裏面的方法。那些數學符號或者不容易敲打的符號會嚴重的影響寫僞代碼的快感。我以爲《The algorithm design manual》裏面的僞代碼格式就不錯，可是由於實際中的僞代碼可能比寫一個算法複雜一些，因此還須要添加一些其餘元素，好比我本身的僞代碼格式其實有點像是Python代碼。寫僞代碼的主要目的是弄清楚實現的邏輯。
   在第0步，其實不是每一個人一開始都能寫得清晰的，須要經過長期寫做來鍛鍊。因此不管是寫日記，寫博客仍是寫情書，堅持下去，都能對往後寫代碼的能力有所幫助。
   時間不早了，最後再附送兩個程序員生活小貼士：
2. 作筆記，OneNote或者EverNote，把遇到的bug，看到過的好trick，好文章，好照片都記錄下來。
3. Eat your own dog food. 那些本身寫過的能夠抽離出來重用的代碼或者腳本整理好同步到github或者bitbucket上去，不斷增長和改善本身的dog food。
   Update 2015-07-22:評論裏幾我的提到free(p);p=NULL;是一個合理的建議。我想支撐這一點的理由是「懸空指針被複用的話很危險」。可是在你的程序裏面每個p都存在被複用的可能嗎？並非。因此每一次寫下free(p)的時候就應該想這個問題。而後再考慮是否寫p=NULL；由於懼怕而寫下的這些冗餘代碼會極度影響代碼的美觀，這也是我認爲從free(p)到p=NULL不該該成爲一個順手的習慣的緣由。---https://www.youtube.com/watch?v=6QsTfL-uXd8

閉嘴看我秀：

說一些基礎的、適用於初學者的好習慣。

1.在開始編碼以前先規劃和組織代碼

在項目的開始階段，不要上手直接寫代碼，必定要先肯定代碼的分層和架構。該分層和架構在必定程度上決定了將來整個項目的代碼風格和維護性，對於項目的長期維護，代碼架構的設計是一件很是重要的事情。
代碼架構能夠提供更好的可讀性和可維護性。你們可能還記得剛開始寫代碼的時候，全部的代碼都會集中在一個文件，甚至一個函數中，好比

 

 

隨着需求的增加，代碼量的擴大，這樣的代碼是很難閱讀和進行維護的，因而咱們會使用重構的手段去讓代碼更便於維護和閱讀：

 

 

進一步，咱們將代碼分散在不一樣的文件、文件夾中，經過良好的命名，咱們甚至能夠在不去看具體的代碼實現的狀況下，僅僅經過文件名就能判斷出在作的事情：
│   main.c
│
├───job
│       first.c
│       second.c
│       third.c
│
└───other        
other file
就文件來講，能夠從文件名上，分清哪些是頭文件、哪些是源文件、哪些是第三方庫、還有各類功能模塊的細分等。
就代碼來講，包括統一的命名風格，封裝在同一個文件裏的代碼的相關性足夠強等。
一個好的架構還應該儘量的提升代碼的可擴展性。
你要知道需求變動太TM正常了，新增需求也太TM正常了。所以好的架構，必需要考慮到這些狀況的發生，由於他們是必定會發生的。因此，必定要避免把代碼寫死。

2. 避免大塊重複代碼，小塊也不行

一個很是好的編程習慣是確保爲代碼建立函數或類，以便有時重用。當你的編碼過程當中屢次出現重複的代碼塊，這樣很臃腫、很雞肋，你就應該想他們是否應該封裝成一個函數或類。專門爲能夠反覆使用的功能構建專用文件。例如，數據庫調用（例如打開數據庫鏈接，選擇數據，插入數據，更新數據，刪除數據和關閉鏈接）都應該轉換爲函數。經過沒必要重寫冗餘代碼行，也會使你的工做變得更加容易。你須要作的就是調用該函數，簡單、清潔、並且容易。
例如，如下是將記錄插入MySQL數據庫的PHP函數示例：

 

 

3 . 使用易於閱讀的命名約定

不管你正在開發什麼類型的代碼，命名約定都很重要。你建立的變量名稱，函數名稱，類名稱和任何其餘程序名稱越人性化，你後續的開發和引用就會越容易。由於全部代碼並不都是同一天寫的，並且一個項目每每由不少人共同參與，好的命名約定能夠大大提升編碼效率，還能夠下降你在同事心中的傻逼程度。

 

 

4 .給代碼多添加註釋，即便它看起來很明顯

就算它寫在臉上，也必定要註釋、註釋、註釋。由於當你正在處理代碼的時候，它確定是易懂的，否則你也寫不出來這樣的代碼。可是，當你再次回到該代碼時，你可能徹底看不懂。並且這也會大大減輕同事的負擔，換位思考一下，假如老大讓你改一下同事A沒有註釋的代碼，可能改一下只須要2個小時，看懂得兩天，你內心確定萬匹草泥馬奔騰。

特別是若是該代碼中有大量嵌套元素。對這樣的代碼塊的右括號進行註釋也是一種好習慣。

 

 

5.在構建時測試和調試代碼

每次建立代碼塊時，都應該對其進行測試和調試，以確保它正常工做。不要矇頭就是寫，而後寫完了以後在調試，避免爲了找到錯誤而篩選數百或數千行代碼。不只須要在構建代碼時測試和調試代碼，還須要確保打開全部錯誤報告，以便在實際操做中實際查看錯誤。好比PHP，你還須要確保在php.ini文件或user.ini文件中打開這些設置，該文件一般位於根目錄中。

 

6 - 實現版本控制系統

版本控制是編程的一個重要方面。當你構建一個簡單的軟件時，你可能不會在一開始就考慮版本控制。可是，隨着時間的推移，你將須要改進該代碼，不管它是什麼類型的代碼。並且，隨着你的改進，你將須要跟蹤你的版本。請記住，編程不僅是編寫代碼行，你必須可以正確地組織代碼並跟蹤你的工做。
保留版本也是很好的，這樣你就能夠不時地檢查一下，看看你在以前的版本中作了什麼，或者可能帶回你在先前版本中刪除但如今想要重用部分的代碼。這是一個很好的習慣。所以，你須要一個能夠控制版本的工具好比git。

Ryan：

遇到不清楚或不懂的知識點，先去看官方文檔！先！去！看！官方！！文檔！！！！
不少官方文檔是英文的，硬着頭皮也要看！看着看着就習慣了。
剛開始讀英文文檔會費時間和精力，可是等你回過頭來再看，你會以爲這纔是最恰當的選擇。爲何醬講？
且不說你的英文水平獲得提高（這是程序員沒法迴避的問題），耐性獲得鍛鍊，什麼叫官方文檔？！兩個痣：權威！準確！當你習慣了在百度上百度一些似是而非，似懂非懂的答案時，甚至有的文章觀點徹底不同，你就會懂我在說什麼了。固然，我並無否定網上有好的答案和文章，我本身也常常看別人的博客。只是，做爲初學者，你的水平很難去辨別一些文章，觀點的好壞對錯，而這可能會對你理解一些知識帶來致命的誤導！
因此，做爲初學者，咱們應該多讀官方文檔，不要浮躁，要知道任何成長都沒有捷徑！共勉。

坐家：

可能不算一個編程習慣，算一個工做習慣吧。要懂得拒絕，要懂得說不(知道)，也要懂得主動要工做。拒絕的理由能夠是：忙着呢；這塊不歸我負責；xx更加適合作這個；這個須要老大讚成才能作 …….。這樣你能夠少作不少可有可無的事情，專一於本身負責的或者感興趣的工做上。拒絕主要對普通同事，其餘部門的要求，對老大不能隨便拒絕，只能說不知道。不知道的理由能夠是：沒作過啊；不熟悉啊；很久沒碰這個了 ……。這樣老大會給你更多時間，你能夠把一件事情作好而不是作完。主動要工做：當你不太忙或者當你手上的工做完成時間可預期的時候，向老大要工做。主動選擇那些你負責的和你感興趣的工做要。這樣，當你拒絕和說不知道的時候，老大就不會以爲不爽了。  有些工做是頗有趣的，你不要別人就會要走 :)