好的編程習慣有哪些

這期內容當中小編將會給大家帶來有關好的編程習慣有哪些，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

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

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

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

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

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

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

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

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

上述就是小編為大家分享的好的編程習慣有哪些了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。