軟體工程視角下 const 關鍵字的正確用法

許多開發者視 const 為可有可無的修飾詞，實則它是團隊協作中最有力的「契約工具」。本文從軟體工程角度，系統梳理 const 的四大使用層次，展示其如何在編譯期防禦邏輯錯誤、明確介面語意、降低維護成本。

第一層：標示唯讀常數

const int MAX_COUNT = 100;        // 編譯期常數，防止誤寫
const double PI = 3.1415926535;   // 語意清晰，取代魔術數字

編譯器會攔截任何嘗試修改的操作，強制初始化，杜絕未初始化變數風險。

第二層：指標與 const 的組合語意

記憶口訣：靠近變數名的是指標本身，靠近型別的是指向內容。

第三層：函式參數傳遞契約（輸入/輸出語意）

// 明確宣告：src 為唯讀輸入，dest 為輸出
bool CopyClass(Value &dest, const Value &src);

• 呼叫端一眼辨識哪些參數會被修改，免除追蹤函式內部實作。
• 編譯器在函式內部強制檢查，防止誤寫 src.x = 1。
• 配合 const 參考傳遞大型物件，兼顧效能與安全。

第四層：成員函式的 const 資格（物件不變性承諾）

問題場景

class Value {
public:
    int GetValue() { return _value; } // 非 const 成員函式
private:
    int _value;
};

bool CopyClass(Value &dest, const Value &src) {
    int v = src.GetValue(); // 編譯錯誤！const 物件無法呼叫非 const 成員函式
}

修正：成員函式加 const

class Value {
public:
    int GetValue() const { return _value; } // 承諾不修改 this 指向的物件
private:
    int _value;
};

現在 const Value& 可安全呼叫 GetValue()，介面契約完整閉環。

實戰準則

1. 預設加 const：除非確定需要修改，所有參數、區域變數、成員函式優先加 const。
2. const 正確性傳遞：const 物件只能呼叫 const 成員函式，強制設計者思考「這個操作是否改變狀態」。
3. 避免 const_cast：除非與非 const 介面的 Legacy 程式碼互操作，否則視為設計缺陷。
4. 文檔化效果：const 比註解更可靠，它會被編譯器強制執行。

善用 const，不僅能讓編譯器成為第一道防線，更能在團隊中建立清晰的「不可變文化」，讓程式碼自我說明、經得起重構與時間考驗。