你的程式碼能聞到！如何修復

在本文中，我們將重點介紹10種最常見的程式碼氣味，以及如何對它們進行除臭。如果你是一個新的程式設計師，避免這些，你的程式碼會明顯更好！...

代碼氣味是一塊代碼或通用編碼模式，看起來它可能表明代碼庫的整體結構和設計中存在更深層次的問題。

把代碼氣味看作是任何暗示某段代碼應該被重構的跡象。這並不是因為代碼有缺陷或者沒有功能——通常情況下，有臭味的代碼運行得很好——而是臭味的代碼通常很難維護和擴展，這可能會導致技術問題（尤其是在大型項目上）。

在本文中，我們將重點介紹10種最常見的代碼氣味，尋找什麼，以及如何去除它們的氣味。如果你是一個新的程序員，避免這些，你的代碼會明顯更好！

1緊耦合

問題

緊密耦合是指兩個對象如此依賴於彼此的數據和/或函數，修改一個對象需要修改另一個對象。當兩個對象耦合得太緊密時，對代碼進行更改可能是一個噩夢，而且每次更改都會引入bug。

例如：

class Worker { Bike bike = new Bike(); public void commute() { bike.drive(); }}

在這種情況下，工人和自行車是緊密耦合的。如果有一天你想開車而不是騎自行車上下班呢？你必須進入工人階級，用與汽車相關的代碼替換所有與自行車相關的代碼。很亂，容易出錯。

解決方案

您可以通過添加抽象層來放鬆耦合。在這種情況下，工人階級不只是想駕駛自行車，還想駕駛汽車，也許是卡車，甚至可能是摩托車。這些都是車輛，不是嗎？因此，創建一個Vehicle接口，允許您根據需要**和替換不同的車輛類型：

class Worker { Vehicle vehicle; public void changeVehicle(Vehicle v) { vehicle = v; } public void commute() { vehicle.drive(); }}interface Vehicle { void drive();}class Bike implements Vehicle { public void drive() { }}class Car implements Vehicle { public void drive() { }}

2上帝的目標

問題

一個上帝的對象是包含太多變量和函數的大規模類/模塊。它“知道得太多”、“做得太多”，這有兩個原因造成問題。首先，其他類/模塊過度依賴於此類/模塊來獲取數據（緊密耦合）。其次，隨著所有東西都被塞進同一個地方，程序的整體結構變得渾濁。

解決方案

以上帝為對象，根據它們所存在的問題來分離其數據和函數，然後將這些分組轉換為對象。如果你有一個上帝的物體，它可能會更好的組成許多較小的物體。

例如，假設您有一個龐大的用戶類：

class User { public String username; public String password; public String address; public String zipcode; public int age; ... public String getUsername() { return username; } public void setUsername(String u) { username = u; }}

您可以將其轉換為以下內容的組合：

class User { Credentials credentials; Profile profile; ...}class Credentials { public String username; public String password; ... public String getUsername() { return username; } public void setUsername(String u) { username = u; }}

下次您需要修改登錄過程時，您不必遍歷大量的用戶類，因為Credentials類更易於管理！

三。長函數

問題

一個長函數就是它聽起來的樣子：一個長得太長的函數。雖然對於一個函數來說，代碼行數“太長”並沒有一個具體的數字，但當你看到它時，你就會知道它是什麼。這幾乎是上帝對象問題的一個更嚴格的範圍版本——一個長函數有太多的責任。

解決方案

長函數應該被分解成許多子函數，每個子函數都被設計用來處理單個任務或問題。理想情況下，原始的長函數將變成子函數調用列表，從而使代碼更清晰、更易於閱讀。

4參數過多

問題

一個函數（或類構造函數）需要太多參數，這有兩個原因。首先，它使代碼可讀性降低，並且使測試變得更困難。但是第二，更重要的是，它可能表明，該函數的目的過於模糊，並且試圖處理太多的責任。

解決方案

雖然“太多”對於參數列表來說是主觀的，但是我們建議對任何超過3個參數的函數都要小心。當然，有時一個函數有5個甚至6個參數是有意義的，但前提是有充分的理由。

大多數時候，沒有一個，代碼最好將該函數分解為兩個或多個不同的函數。與“長函數”代碼氣味不同，這一點不能僅僅通過用子函數替換代碼來解決——函數本身需要被劃分為包含單獨職責的單獨函數。

5名稱錯誤的標識符

問題

一個或兩個字母的變量名。無法描述的函數名。過度修飾的類名。用它們的類型標記變量名（例如，b\u是一個布爾變量）。最糟糕的是，在一個代碼庫中混合使用不同的命名方案。所有這些都會導致代碼難以閱讀、難以理解和維護。

解決方案

為變量、函數和類選擇好的名稱是一項很難學會的技能。如果您要加入一個現有的項目，請對其進行梳理，看看現有標識符是如何命名的。如果有一個風格指南，記住它並堅持它。對於新項目，考慮形成自己的風格指南並堅持下去。

一般來說，變量名應該簡短，但具有描述性。函數名通常應該至少有一個動詞，並且應該立即從它的名稱就可以看出函數做了什麼，但是要避免塞進太多的單詞。類名也是如此。

6幻數

問題

你瀏覽了一些別人寫的代碼，發現了一些硬編碼的數字。也許它們是if語句的一部分，或者是一些似乎沒有意義的神祕計算的一部分。你需要修改函數，但是你不能理解數字的含義。劃傷頭部。

解決方案

在編寫代碼時，應該不惜一切代價避免這些所謂的“幻數”。硬編碼的數字在編寫時是有意義的，但是它們很快就會失去所有的意義——特別是當其他人試圖維護您的代碼時。

一種解決方案是留下解釋數字的註釋，但更好的選擇是將魔術數轉換為常量變量（用於計算）或枚舉（用於條件語句和開關語句）。通過給神奇數字一個名字，代碼一看就變得無限可讀，而不太容易發生錯誤的變化。

7深巢

問題

有兩種主要的方法來結束深度嵌套的代碼：循環和條件語句。深度嵌套的代碼並不總是不好的，但可能會有問題，因為它很難解析（尤其是在變量命名不好的情況下），甚至更難修改。

解決方案

如果您發現自己編寫了一個雙循環、三重循環，甚至是四倍循環，那麼代碼可能試圖到達超出自身的太遠，無法找到數據。相反，提供一種方法，通過函數調用任何對象或模塊包含數據來請求數據。

另一方面，深度嵌套的條件語句通常是您試圖在單個函數或類中處理過多邏輯的標誌。實際上，深嵌套和長函數往往是並行不悖的。如果您的代碼有大量的switch語句或嵌套的If-then-else語句，那麼您可能需要實現一個狀態機或策略模式。

在缺乏經驗的遊戲程序員中，深度嵌套特別普遍！

8未處理的異常

問題

例外是強大的，但很容易被濫用。懶散的程序員如果不正確使用拋出catch語句，那麼調試會變得更困難，如果不是不可能的話。例如，忽略或隱藏捕獲的異常。

解決方案

與其忽略或隱藏捕獲到的異常，不如至少打印出異常的堆棧跟蹤，這樣調試器就可以使用了。讓你的程序默默地失敗，肯定會讓你將來頭疼！另外，更喜歡捕獲特定異常而不是一般異常。在我們的文章中瞭解更多關於如何正確處理異常的信息。

9重複代碼

問題

在程序的多個不相關區域中執行相同的精確邏輯。後來，您意識到需要修改該邏輯，但不記得實現它的所有地方。你最終只改變了8個地方中的5個，導致了錯誤和不一致的行為。

解決方案

重複代碼是轉換為函數的主要候選代碼。例如，假設您正在開發一個聊天應用程序，並編寫以下代碼：

String queryUsername = getSomeUsername();boolean isUserOnline = false;for (String username : onlineUsers) { if (username.equals(queryUsername)) { isUserOnline = true; }}if (isUserOnline) { ...}

在代碼的其他地方，您意識到您需要執行相同的“此用戶是否聯機？”檢查。您可以將循環拉出，而不是複製粘貼循環，而是將其拉出函數：

public boolean isUserOnline(String queryUsername) { for (String username : onlineUsers) { if (username.equals(queryUsername)) { return true; } } return false;}

現在，在代碼的任何地方，都可以使用isUserOnline（）檢查。如果您需要修改這個邏輯，您可以調整這個方法，它將應用於任何調用它的地方。