#region 指令正確用法：別讓折疊成為掩蓋爛代碼的藉口

誤區一：在大型方法內用 #region 分隔邏輯塊

public void DoSomething() {
    #region Decide if I should do something
    if (needToDoSomething && haventDoneToday) shouldDo = true;
    else { /* 複雜邏輯 */ }
    #endregion
    if (shouldDo) { done++; }
}

折疊後雖整潔，但本質上只是把本應拆分的私有方法內嵌在大方法裡。單一職責原則告訴我們：直接提煉為 private bool ShouldIDoSomething()，降低認知負荷、利於單元測試。

誤區二：用 #region 包裹整個公共方法

#region Get Customer
public void GetCustomer() { /* ... */ }
#endregion
#region Save Customer
public void SaveCustomer() { /* ... */ }
#endregion

折疊後只剩 [Get Customer] [Save Customer]，閱讀者每次都得展開才能看實作，反而增加操作成本。這類分組完全多餘，IDE 已提供大綱檢視與導航功能。

誤區三：在類別層級用 #region 隔離職責

public class PriceCalculator {
    public decimal CalculatePrice() { /* ... */ }
    #region Discount Calculation
    private decimal CalculateDiscount() { /* ... */ }
    private bool CanApplyDiscount() { /* ... */ }
    #endregion
}

PriceCalculator 同時負責「價格計算」與「折扣計算」，違反單一職責原則。正確做法是提煉 DiscountCalculator 類別，透過依賴注入組合，而非用區塊掩飾設計缺陷。

#region 的正統用法：組織類別結構

唯一推薦場景：依成員類型分組，協助快速掌握類別架構：

public class SomeClass {
    #region Events
    // 事件聲明
    #endregion
    #region Fields
    // 私有欄位
    #endregion
    #region Properties
    // 屬性
    #endregion
    #region Methods
    // 方法
    #endregion
    #region Nested Types
    // 巢狀類型
    #endregion
}

這樣折疊後能一眼看到類別由哪些結構組成，不隱藏業務邏輯，純粹輔助導航。

核心原則

1. Region 不能消除複雜度，只能隱藏代碼。 真正的降低複雜度靠：小巧清晰的方法、單一職責的類別、良好的命名。
2. 寫 #region 前先問自己：這段代碼能不能提煉成方法/類別？ 能的話動手重構，不能才考慮區塊。
3. 不要因為能用就用。 過度折疊等同於製造「隱形技術債」。

當你寫出乾淨、模組化的代碼時，甚至會發現 #region 根本不需要。