Google C++ 風格指南（二）：作用域管理與命名空間最佳實踐

前言

在大型 C++ 專案中，作用域管理直接關係到程式碼的可維護性、編譯效率與執行時期的穩定性。Google C++ 風格指南的第二部分深入探討了命名空間、巢狀類別、非成員函數、區域變數與全域變數的使用規範。本文將系統整理這些核心規則，並輔以實務說明，協助開發者寫出更乾淨、更安全的 C++ 程式碼。

一、命名空間

核心概念與權衡

命名空間將全域作用域劃分為獨立的命名區域，有效防止符號衝突。例如，兩個專案皆定義 class Foo，若分別置於 project1::Foo 與 project2::Foo，即可共存。然而，命名空間與類別同樣提供巢狀命名軸線，過度使用反而增加認知負擔；且在標頭檔使用未命名命名空間易違反單一定義原則（ODR）。

未命名命名空間：.cc 檔的專屬工具

強烈建議在 .cc 實作檔中使用未命名命名空間，限制符號僅在該編譯單元內可見，避免連結期衝突：

namespace { // .cc 檔案內部
// 內容無需縮排
enum { UNUSED, EOF, ERROR };
bool AtEof() { return pos_ == EOF; }
} // namespace  // 以註解標示結束

禁令：.h 檔嚴禁使用未命名命名空間。

具名命名空間：專案級隔離

• 將除 #include、全域宣告、類別前置宣告外的整個原始檔包裹於具名命名空間中。
• 命名空間名稱建議基於專案或路徑（如 myproject::module）。
• 禁止 在標頭檔頂層使用 using namespace foo; 污染全域命名空間。
• 允許在函式、方法或類別內部使用 using ::foo::bar; 或命名空間別名 namespace fbz = ::foo::bar::baz;。
• 絕對不要在 std 命名空間宣告任何實體，需包含對應標頭檔。

二、巢狀類別

巢狀類別（成員類別）適用於「僅在外層類別內部使用」的情境。優點是封裝性強、不污染外部作用域；缺點是前置宣告受限於外層類別定義，導致依賴傳播。結論：除非作為介面一部分（如選項類別），否則勿設為 public。

三、非成員函數、靜態成員函數與全域函數

• 優先使用命名空間內的非成員函數或靜態成員函數，避免全域函數污染全域作用域。
• 非成員函數不應依賴外部變數，並置於命名空間中。
• 僅為封裝無共享靜態資料的靜態成員函數而建立類別，不如直接使用命名空間。
• 若函數僅在單一 .cc 使用，以未命名命名空間或 static 限制鏈結可見性。

四、區域變數：就近宣告、初始化優先

• 在最小作用域宣告變數，離首次使用越近越好。
• 宣告時直接初始化（int j = g();），避免「宣告後賦值」（int i; i = f();）。
• C++ 支援 for (int i = 0; ...)、if (const char* p = ...) 等作用域宣告，善用之。
• 效能陷阱：迴圈內建立物件會重複呼叫建構/解構函式。對於大型物件，應移至迴圈外：

// 低效：建構/解構各呼叫 1,000,000 次
for (int i = 0; i < 1000000; ++i) { Foo f; f.DoSomething(i); }

// 高效：僅呼叫 1 次
Foo f;
for (int i = 0; i < 1000000; ++i) { f.DoSomething(i); }

五、全域變數：嚴格限制與替代方案

• 禁止 類別型別（含 STL 容器）的全域變數，因初始化順序未定義易導致難以除錯的錯誤。
• 僅允許內建型別、無建構函式的 POD 結構體、常數字串（const char kStr[] = "...";）。
• 若確需類別型別全域物件，採用 Singleton 模式延遲初始化。
• 多執行緒環境下，嚴禁 非常數全域變數（含靜態成員變數）。
• 永遠不要用函式回傳值初始化全域變數。
• 替代方案：改為類別靜態資料成員、未命名命名空間變數、或 static 區域變數。

總結：作用域設計的核心原則

1. 最小化可見性：未命名命名空間、static、區域作用域，層層收斂符號範圍。
2. 避免污染：拒絕 using namespace、全域函數/變數、類別型別全域物件。
3. 初始化安全：就近初始化、避免跨編譯單元依賴、多執行緒環境下禁用非常數全域狀態。
4. 效能感知：減少不必要的建構/解構、利用編譯期計算、善用移動語意（C++11 後）。

遵循這些規範，不僅能消除符號衝突、降低耦合，更能讓程式碼在大型專案中保持清晰、可靠、高效。