在編程成為乾淨的代碼忍者時，我們應該認識到最常見的代碼氣味的集合。
> Photo by Aisha Askhadova on Unsplash
您是否曾經在閱讀代碼時感覺到告訴您某些錯誤的感覺？ 那種"看起來有些不好"的感覺，但是，您仍然無法確切地知道問題出在哪裡嗎？
這種怪異的感覺是，您從代碼中得到的是正確的直覺。 這些是不良做法，通常稱為代碼氣味。
能夠發現氣味並實現更清潔的解決方案將幫助您在編程生涯中取得重大進步，幫助您自學如何編寫乾淨的代碼。
臨時字段
即使試圖避免這種情況，也有一種常見的情況是我們有條件地設置一個類字段。 由於您希望使用類中的所有字段，因此這可能會使代碼的清晰度降低。
好的解決方案是提取一個新類，以為此字段創建一個位置並移動相關功能。 另外，最好引入一個特殊情況，當變量無效時，該情況會創建另一個類。
龐大的類
當一個類開始增長並且包含太多字段時，重複的代碼就在後面。 而且我們討厭重複的代碼！ 因此，我們應注意使其儘可能小。
您可能會發現自己重構了一個無限類，因為它可以處理無關的操作，第一個解決方案是使用類提取來分離代碼。
但是由於我們喜歡簡單的解決方案，因此最快的解決方案可能是消除類本身內部的冗餘。 例如，要這樣做，您可以採用帶有大量共享代碼的長方法，然後將它們拆分為較小的方法，以便您可以根據需要進行組合，從而避免任何形式的重複。
循環
即使它們長期以來一直是編程的核心，並且仍然有用，但仍有許多替代方法可以幫助我們的代碼更具描述性，並讓我們對代碼一見鍾情。
使用.map或.filter之類的管道方法有助於立即瞭解結構的操作方式，從而減少了更強制性的代碼所造成的抽象。
懶元素
有時我們實現一個新結構，目的是在以後重用它，或者使我們的代碼更整潔和更具描述性，但是最後，我們意識到它是無用的，並且我們從未在代碼庫中使用過它。 犧牲這部分代碼！
例如，我們可以對函數和類使用內聯技術來實現此結果。
神秘的名字
根據菲爾·卡爾頓的說法：
在計算機科學中只有兩件難事：緩存無效和命名。
我完全同意他的看法。 正確命名變量，函數和類可以大大提高代碼的清潔度！ 它可以確保描述性更強的代碼，減少註釋的使用，並使將來的開發人員在閱讀代碼時更加輕鬆！
請記住，一臺機器可以理解0和1，我們的代碼稍後會翻譯成該語言。 但是，我們編寫的代碼是為人類編寫的，因此請編寫代碼，就像向6歲的孩子解釋代碼一樣。
> Photo by Ben White on Unsplash
全局數據
這是每個開發人員在編寫代碼時都應記住的事情，因為可以從任何地方訪問（尤其是可變的）代碼，如果修改後會產生意外的行為。
全局數據最常見的示例是全局變量。 我們可以使用的第一個防禦機制是用函數封裝變量，因為這至少提供了更好的方法來控制其訪問並查看其修改位置。
但是，我建議您始終避免使用全局變量和一般的全局數據。 始終存在不同的方法來實施可行的解決方案
註釋過多
我並不是說註釋自己的代碼很不好，但是如果您編寫的程序具有良好的命名並遵循簡潔的代碼模式，則代碼將是不言自明的，從而減少了文件的樣板並提高了代碼庫的可維護性。
當您需要編寫註釋時，請首先嚐試重構代碼，以使任何註釋都變得多餘。 馬丁·福勒。
長參數列表
您認為期望6-7個（或更多）參數的有序列表的函數不會引起混淆嗎？ 有這麼長的列表更容易出現錯誤並降低可讀性。
通常，我們可以通過引入參數對象來解決此問題。 這樣做包括將適合在一起的一長串參數組合到一個新對象中，並將其作為唯一參數傳遞。 這具有很多好處，因為我們可以在函數調用之前定義參數對象，而屬性順序無關緊要。 這是我們在任何參數列表中都應始終考慮的問題。
另一個選擇是將函數組合成一個類，但這通常在某些函數共享相同的參數值時使用，以便我們可以捕獲它們。
重複的代碼
代碼複製是非常專業的代碼庫中存在的另一種常見反模式，我們應該盡力減少它，以保持代碼乾淨，並避免在功能改變時在不同位置更改同一代碼。
有多種情況可以幫助刪除重複的代碼，但是最常見的解決方案是創建一個新函數來封裝該邏輯的解決方案，或者在代碼不完全相同的情況下，可以重新排列代碼，以使它們相似 所有項目都在一起以便於提取（Slide語句）。
> Photo by Daniel Cheung on Unsplash
冗長功能
在我看來，為人類編寫代碼是成為優秀程序員的黃金法則。 長函數是這種思維方式的最大敵人之一，因為長函數使我們的代碼可讀性降低。
函數需要描述它們的功能，並應專注於一個孤立的任務，以便我們在必要時可以重用它們。 通常，隨著功能的變長，其複雜性也會隨之增加，並且代碼的可維護性也會降低。
在大多數情況下，解決此問題的方法是將一部分代碼提取到新函數（提取函數）中，並在必要時重新使用。
總結
照顧好您的代碼並努力理解如何進行改進，這使我一直熱愛代碼和編程。 希望您能分享我的看法，並希望您喜歡這篇文章。 我將大部分學習歸功於Martin Fowler和他的Refactoring書，我認為這是必讀的！
有關該主題的評論，分享和討論總是受到讚賞。 我很樂意回答您的任何問題！
隨時通過Linkedin與我聯繫
(本文翻譯自Marco Antonio Ghiani的文章《10 Programming Code Smells That Affect Your Codebase》，參考：https://levelup.gitconnected.com/10-programming-code-smells-that-affect-your-codebase-e66104e0341d)
