AOP 在 C# 中的探索與實踐（續 2）：解析器整合與 SharpDevelop 代碼審查

解析器原型啟動

開始編寫 AOP 織入器的解析器階段，採用策略：借鑑 SharpDevelop/NRefactory 現有解析器核心，避免重複造輪子。即使是 RC2 版本，原始碼中仍存在可疑邏輯，需審慎審查修正。

發現的可疑代碼片段

IList 比較方法邏輯缺陷

static public int Compare(IList a, IList b, IComparer comparer) {
    if (a == null || b == null) {
        return 1;  // 問題 1：null 比較語意模糊，應拋 ArgumentNullException
    }
    if (a.Count != b.Count) {
        return Math.Sign(a.Count - b.Count);
    }
    int limit = (a.Count < b.Count) ? a.Count : b.Count;  // 問題 2：前已檢查 Count 相等，此處冗餘
    for (int i = 0; i < limit; i++) {
        if (a[i] is IComparable && b[i] is IComparable) {  // 問題 3：忽略傳入的 comparer！
            int cmp = comparer.Compare(a[i], b[i]);
            if (cmp != 0) return cmp;
        }
    }
    return a.Count - b.Count;  // 永遠回傳 0
}

問題分析

Mono 專案已修正

查閱 Mono 來源碼確認上述邏輯已重寫。懷疑原作者可能在非最佳狀態下撰寫（酒後編程？）。這提醒我們：即使成熟開源專案，核心演算法也需獨立驗證。

解析器整合進度

• ✅ NRefactory 核心組件引入專案
• ✅ 基本 AST 遍歷器實作
• ✅ 類別/方法/屬性節點識別
• 🔄 Pointcut 運算式解析器開發中
• ⏳ Advice 織入邏輯待實作
• ⏳ PDB 符號重寫待研究

下一步重點

1. 完成 Pointcut DSL 設計（支援命名空間、類別、方法模式、屬性過濾）
2. 實作 Around Advice 的 IL 插入邏輯（方法序言/結語、try/finally 區塊）
3. 建立單元測試套件驗證織入正確性
4. 效能基準：織入前後 IL 體積、執行速度對比

心得

解析器整合看似捷徑，實則需要深入理解上游專案架構。SharpDevelop 代碼品質參差不齊，核心解析器尚可，但工具方法庫需逐一審查。建立自動化代碼品質閘門（StyleCop、Roslyn Analyzer、單元測試覆蓋率）對維護織入器專案至關重要。