無論是在招聘中還是領導者下達要求時，程序員都必須養成良好的編程習慣，但是到底好的編程習慣是什么呢？其實好的編程有很多，例如：簡明代碼、消除幻覺、代碼注釋、代碼低耦合、避開上帝對象、拒絕長函數、有意義的標識符命名、避免深層次的嵌套等等都是好的編程習慣。“但是道理大家都懂，可是做起來卻是非常難的。”今天本文就詳細介紹一下好的編程習慣，讓我們看看您的編程習慣是否“優秀”。

　　一、簡明代碼

您在程序的多個獨立部分中執行相同的邏輯代碼塊，然后發現需要修改該邏輯代碼塊，但不記得執行它的所有位置，假定您最終只修改了5個位置，而實際上需要更改8個位置的代碼塊，這將導致結果錯誤。轉換成函數通常是一種較好的習慣，因此如果您需要修改這個邏輯代碼塊，只需修改這個方法，然后將它應用到所有調用它的地方。

　　二、消除幻覺

在瀏覽別人寫的代碼時，你會發現其中有一些是硬編碼的數字。他們可能是 if語句的一部分，或某些難以理解的計算，似乎沒有什么意義，當您需要修改模塊時，卻不能理解數字的含義，這會讓您非常煩惱。所以，在編程的時候，一定要不惜一切代價避免這些所謂的“錯數”。硬碼數字在書寫過程中有一定意義，但它們很快就失去了意義，尤其是當其他人試圖維護您的代碼時。一個解決辦法是留下數字的注釋，但是更好的辦法是把幻數轉換成常量變量(用于計算)或枚舉（用于 if語句和 switch語句）。代碼的可讀性是通過給幻數取一個名字來實現的，并且不容易出錯。

　　三、代碼注釋

這些代碼到處都沒有注釋。不需要對函數進行功能注釋，不需要概述類，不需要解釋算法等。可以這樣說，寫得好的代碼不需要注釋，但是實際上，即使是最好的代碼也沒有注釋容易理解。當您編寫注釋時，請記住，您的目標是解釋代碼塊為何存在，而不是解釋它正在做什么。注解可以幫助您更好地理解自己和別人的代碼，并且減少工作，所以不要忽視它們。

　　四、代碼低耦合

低耦合性是結構良好的程序的特征，低耦合性程序的可讀性、可維護性、可復用性和擴展性都比較好，而緊耦合模塊或系統過于緊密，以致在對一個對象進行修改時，可能會發生相互調用。如果兩個對象耦合得太緊，修改代碼就會成為一場噩夢，而且更容易在每次修改中引入 bug。

　　五、避開上帝對象

bondObject是一個大型的類或模塊，其中包含太多的變量和函數。由于以下兩個原因，“知道的太多”和“做的太多”都會導致一些問題。第一，其他的類或模塊將變得對數據的過度依賴（緊密耦合）。第二，因為所有的代碼都擠在一個地方，所以整體結構混亂。與上帝對象相比，將它分解成許多小對象可能更好。

　　六、拒絕長函數

正如它的名字一樣，長函數意味著函數太長。盡管對于一個函數來說，沒有一個數字代表多少行代碼“太長”，但是當您看到這個函數時，您就知道它是否太長了。長長的函數意味著包含太多的功能性實現。通常應將長函數分解為多個子函數，其中每個子函數都可用于單個任務或問題。理論上，原始的長函數會變成子函數調用列表，這樣代碼就會更清晰，更易讀。

　　七、有意義的標識符命名

變量名有一兩個字母，函數名沒有明顯意義，類名被過度修飾，變量名被使用變量類型進行標記（例如，b_isCounted代表 Boolean變量），或者混合使用一段代碼中不同的命名規則，所有這些都會導致代碼難以閱讀，難以理解，難以維護。一般來說，變量名應該是簡短的，但是描述性的。一般情況下，函數名應該至少包含一個動詞，而且函數名應該顯示該函數的功能，但不要使用太多的詞，比如類名。

　　八、避免深層次的嵌套

深奧的嵌套代碼并不總是糟糕的，但是可能會有問題，因為它很難理解，尤其是當變量沒有正確命名時，更是如此。如果您發現自己正在編寫一個雙重、三重甚至四重 for循環，那么代碼可能會試圖在超出您自己能力的地方尋找數據。然后，您應該提供一種方法，讓包含該數據的對象或模塊函數調用能夠請求該數據。而更深層次的嵌套 if語句則表示您嘗試在一個函數或類中處理過多的邏輯代碼塊。實際上，深層次的嵌套和長函數經常同時出現。如果您的代碼中有大量 switch語句或嵌套的if-then-else語句，則可能需要實現 status或 policy模式。

以上就是關于好的編程習慣是什么的全部內容介紹，當然好的編程習慣不止是這些，想了解更多編程習慣的信息，請繼續關注中培偉業。