1. 如果陳述降低了可讀性并增加認知負荷，則深深嵌套了，使代碼更難進行調(diào)試和測試。 2。他們經(jīng)常通過將多個關(guān)注點結(jié)合在一個功能中來違反單一責(zé)任原則。 3.帶有早期回報的后衛(wèi)條款可以使邏輯平坦并提高清晰度。 4.將條件提取到描述性功能上可以增強可重復(fù)性和可讀性。 5。多態(tài)性或策略模式可以用更清潔的對象設(shè)計替代類型或狀態(tài)的條件。 6。使用字典或查找表映射條件來聲明動作，從而減少/elif鏈。 7。對于復(fù)雜的工作流程，狀態(tài)機或規(guī)則引擎更有效地對外部化和管理復(fù)雜的邏輯。 8。淺嵌套（1-2個級別）在不掩蓋流動的情況下清楚地表達意圖時可以接受。 9。嵌套條件的重構(gòu)通過解決潛在的設(shè)計問題來提高魯棒性，可檢驗性和可維護性。 10。當(dāng)凹痕超過兩個級別時，請考慮重構(gòu)以簡化 - 通常，通?？梢詫崿F(xiàn)且可取的結(jié)構(gòu)。

if陳述在代碼庫中是常見的景象，尤其是在早期迭代或緊迫的截止日期。雖然起初它們似乎無害，但深度嵌套的條件通常會標志著代碼的氣味：暗示基礎(chǔ)設(shè)計可能更清晰，更可維護或更容易測試。當(dāng)邏輯將自己埋在if的層中時， else if ， else ，它變得更難閱讀，調(diào)試和擴展。

讓我們探討為什么if S有問題，如何發(fā)現(xiàn)它們以及清理它們的實用策略。

為什么深度嵌套的條件是一個問題

在他們的核心中， if陳述并不是固有的，則嵌套了。單個層次的筑巢通常很好。但是，當(dāng)您看到三個，四個或更多層次的深處時，就會出現(xiàn)幾個問題：

• 降低的可讀性：每個凹痕層次都迫使讀者牢記更多的上下文。
• 認知負荷增加：了解所有可能的執(zhí)行路徑變得困難。
• 較高的錯誤風(fēng)險：在錯誤的塊內(nèi)錯過邊緣案例或錯位邏輯很容易。
• 更難測試：更多的分支意味著更多的測試用例和每個分支機構(gòu)的設(shè)置復(fù)雜。
• 違反單一責(zé)任原則：具有許多嵌套條件的功能通常會做得太多。

氣味的例子：

如果user.is_authenticated（）：
    如果user.has_permission（）：
        如果user.subscription_active（）：
            如果不是user.rate_limited（）：
                ＃最后，做一些有用的事情
                process_request（）

這種厄運的金字塔使很難看到快樂的道路并掩蓋了意圖。

如何識別氣味

在您的代碼中查找這些危險信號：

• 有條件筑巢的兩個以上的壓痕。
• 重復(fù)檢查同一對象或狀態(tài)。
• 最終埋葬主要動作的長長方法。
• 跨多個功能重復(fù)的條件。
• 諸如# TODO: refactor this mess （開玩笑...有點）。

即使邏輯似乎正確，如果要花費10秒鐘以上才能了解發(fā)生了什么，也可能是時候進行重構(gòu)了。

制定和簡化的策略

這是可靠的可降低筑巢和提高清晰度的技術(shù)：

1。后衛(wèi)條款 /提早回報

當(dāng)未達到前提條件時，請盡早退出，而不是將主邏輯包裹在層層if block中。

重構(gòu)版本：

 def handle_request（用戶）：
    如果不是user.is_authenticated（）：
        返回“未經(jīng)授權(quán)”
    如果不是user.has_permission（）：
        返回“禁止”
    如果不是user.subscription_active（）：
        返回“訂閱過期”
    如果user.rate_limited（）：
        返回“速率限制超過”

    返回process_request（）

這種線性結(jié)構(gòu)更容易遵循和測試。

2。將條件提取到描述函數(shù)中

將復(fù)雜或重復(fù)的檢查變成命名良好的功能。

例子：

 def can_process_request（用戶）：
    返回（user.is_authenticated（）和 
            user.has_permission（）和 
            user.subscription_active（）和 
            不是user.rate_limited（））

現(xiàn)在主要邏輯變?yōu)椋?/p>

如果can_process_request（用戶）：
    process_request（）
別的：
    返回“無法處理請求”

這可以提高可讀性和可重復(fù)性。

3。使用多態(tài)性或策略模式（如果適用）

如果基于類型或狀態(tài)的邏輯分支，請考慮用類或策略代替條件。

例如，而不是：

如果user.type ==“ admin”：
    水平= 5
elif user.type ==“主持人”：
    水平= 3
elif user.type ==“ premium”：
    水平= 2
別的：
    水平= 1

定義實現(xiàn).access_level()方法的不同用戶角色類。這完全消除了分支，使添加新角色更加容易。

4。地圖條件到動作

當(dāng)您有清晰的條件映射到結(jié)果時，請使用字典或查找表。

例子：

處理者= {
    （'admin'，true）：handing_admin_active，
    （'admin'，false）：hander_admin_inactive，
    （'用戶'，true）：handing_premium_user，
    （'用戶'，false）：handle_regular_user，
}

action = handlers.get（（（user.role，user.is_premium）））
如果行動：
    返回操作（用戶）

這用聲明邏輯替換了if/elif的網(wǎng)絡(luò)。

5。引入復(fù)雜工作流的狀態(tài)或規(guī)則引擎

對于具有許多相互依賴規(guī)則的業(yè)務(wù)邏輯（例如，資格檢查，定價引擎），請考慮使用規(guī)則引擎或狀態(tài)機。這些工具將邏輯外部化并使其可配置而不是硬編碼。

什么時候可以接受？

并非所有的嵌套都是邪惡的。明確意圖的淺嵌套（1-2個級別）非常好。例如：

如果user.logged_in：
    如果user.is_suspended：
        show_warning（）
    別的：
        show_dashboard（）

這是可讀和合乎邏輯的。鑰匙是意圖的- 如果嵌套闡明了流動，那就可以了。如果它掩蓋了它，那是一種氣味。

最后的想法

嵌套if陳述是癥狀，而不是疾病。真正的問題通常是缺乏關(guān)注，抽象不佳或不受管理的復(fù)雜性的分離。通過使用早期回報，提取功能并在適當(dāng)?shù)那闆r下應(yīng)用設(shè)計模式，您可以將糾結(jié)的邏輯轉(zhuǎn)換為干凈的表達代碼。

重構(gòu)嵌套條件不僅僅是美學(xué)，它使您的代碼更加健壯，可測試和更容易理解其他人（以及未來）。

基本上：如果您縮進了兩個級別，請停下來問：我可以做這個奉承嗎？通常，答案是肯定的。

以上是嵌套為代碼氣味：識別和糾正過度復(fù)雜的邏輯的詳細內(nèi)容。更多信息請關(guān)注PHP中文網(wǎng)其他相關(guān)文章！