Effective C# 原則 4：以條件屬性取代 #if 編譯指示區塊

#if/#endif 易被濫用，導致程式碼難讀、難除錯、不同建構配置行為不一致。C# 提供條件屬性（[Conditional("SYMBOL")]），針對方法啟用/停用呼叫，結構清晰、編譯器最佳化、避免常見陷阱。

傳統 #if 缺陷範例

// 錯誤：DEBUG 時 msg 賦值，RELEASE 時 msg 為 null → 輸出空行
string msg = null;
#if DEBUG
msg = GetDiagnostics();
#endif
Console.WriteLine(msg); // RELEASE 輸出空行，非預期行為

散落的 #if 讓邏輯支離破碎，除錯時需心理模擬不同配置下的程式碼。

Conditional 屬性機制

[Conditional("DEBUG")]
private void CheckState()
{
    var method = new StackTrace().GetFrame(1).GetMethod().Name;
    Debug.Assert(_lastName != null, method, "Last Name cannot be null");
    Debug.Assert(_lastName.Length > 0, method, "Last Name cannot be blank");
    Trace.WriteLine($"CheckState for Person: called by {method}");
}

// 呼叫端：
public string LastName
{
    get { CheckState(); return _lastName; }
    set { CheckState(); _lastName = value; CheckState(); }
}

編譯器行為

• DEBUG 定義：保留 CheckState() 呼叫，方法本體編譯進組件。
• DEBUG 未定義：移除所有呼叫點，方法本體仍編譯進組件但不載入記憶體、不 JIT 編譯（除非被呼叫）。

相當於：

// DEBUG 定義時
get { CheckState(); return _lastName; }
// DEBUG 未定義時
get { return _lastName; }

多條件與邏輯組合

• OR 關係：多個 [Conditional] 屬性並列。[Conditional("DEBUG"), Conditional("TRACE")] → 任一定義即啟用。
• AND 關係：需自行定義組合符號。

  
  #if DEBUG && TRACE
  #define BOTH
  #endif
  [Conditional("BOTH")]
  void Method() { ... }

限制與規範

• 僅適用於回傳 void 的方法。
• 不可套用於方法內程式碼區塊、屬性、建構函式、非 void 方法。
• 方法不得有副作用（修改狀態、回傳值），否則移除呼叫會改變程式語意。
• 標準庫 Debug.Assert、Trace.WriteLine 皆以此機制實作。

優勢總結

最佳實務

• 診斷、斷言、效能計數、日誌記錄等輔助性功能，全面改用 [Conditional]。
• 將條件邏輯封裝於專用方法，呼叫端保持乾淨。
• 符號定義：專案屬性 → Build → Conditional compilation symbols、或命令列 /define:SYMBOL。

1. 上一篇文章： Effective C# 原則 5：永遠提供有意義的 ToString() 實作
2. 下一篇文章： Effective C# 原則 3：善用 is 與 as 運算子，避免強制類型轉換

關於C#

Windows Forms 控制項開發實戰：擴充 TreeView 實現資料繫結與分組

標準 TreeView 控制項功能強大，但缺乏原生資料繫結與

C# 開發 WPF/Silverlight 動畫與遊戲系列教程（十八）：完美精靈之八面玲瓏（僅限 WPF）②

為何要合成大圖？ 若遊戲包含裝備、坐騎等系統，需對圖片源進行

C# 設計模式無廢話系列（五）：Prototype 原型模式

意圖 用原型實例指定創建對象種類，透過拷貝原型創建新對象。

.NET 反射工廠模式深度解析：從簡單工廠到抽象工廠的演進與優化

傳統工廠模式在產品類別眾多時面臨類別爆炸、維護困境。本文詳細