Google C++ 風格指南（八）：規則例外與團隊協作原則

規則例外原則

風格指南旨在統一編碼規範，讓團隊專注於實作而非格式爭辯。但**所有優秀規則皆允許例外**，核心原則是**一致性**（包含既有程式碼的一致性）。

既有不符合風格的程式碼

修改他人程式碼時，優先遵循**原有風格**以保持檔案內部一致。必要時與原作者或負責人溝通確認。

Windows 平台程式碼特殊規範

Windows 程式設計師有獨特習慣（源自 Windows SDK 樣式），但跨平台專案需統一風格。以下為 Windows 程式碼在 Google 風格下的強制調整項：

必須遵守的規範

1. 禁用匈牙利命名法：採用 Google 命名慣例，副檔名用 .cc 而非 .cpp。
2. 優先使用標準 C++ 型別：如用 const TCHAR* 替代 LPCTSTR，僅在呼叫 Windows API 時使用 DWORD、HANDLE 等別名。
3. 編譯警告等級設為 3 或以上，視警告為錯誤處理。
4. 禁用 #pragma once：使用標準 Include Guard，路徑包含專案頂層（如 #include <project/public/tools.h>）。
5. 避免非標準擴展：#pragma、__declspec 等僅在萬不得已時使用，DLL 匯出入巨集化（DLLIMPORT/DLLEXPORT）以利跨平台移除。

極少數允許的例外

1. 多重繼承：僅在實作 COM/ATL/WTL 介面時允許。
2. 異常處理：ATL/STL 內部使用異常，編譯時定義 _ATL_NO_EXCEPTIONS 禁用 ATL 異常；若需 STL 異常可開啟編譯器選項，**但自身程式碼嚴禁撰寫異常處理邏輯**。
3. 預編譯標頭：避免顯式 #include "StdAfx.h"，改用編譯器 /FI 選項強制包含（precompile.cc 除外）。
4. 資源標頭：resource.h 僅含巨集定義，不受風格指南約束。

團隊協作黃金法則

參考常識，保持一致。

• 編輯前閱讀專案既有程式碼風格（縮排、大括號、註解格式）。
• 若既有程式碼 if 後加空格，你也加；若註解用星號圍成盒子，你也照做。
• **局部一致性**同樣重要：單一檔案內風格統一，降低閱讀認知負荷。

結語

風格指南到此告一段落。**程式碼本身才是更有趣的**，盡情享受寫代碼的樂趣吧！