C++編碼規范與指導

版本：1.33

推薦瀏覽設置：

?屏幕分辨率：，1024x768

?字體：中（Ctr：+鼠標滾輪設置）

?最大化本窗口

文檔控制

版本號修改時間修改內容修改人審稿人

1.02004-07-22?創建白楊田振軍

1.12004-08-05?根據審稿意見修改白楊田振軍、

馬浩軍、

葉曉峰

1.22004-08-09?根據審稿意見修改白楊田振軍、

馬浩軍、

?新增RTTI、虛函數和虛

葉曉峰

基類的開銷分析及使用

指導

1.32004-08-10?重寫目錄；一些小改動白楊

廣

大

1.42004-08-10?新增C++成長篇：-）白楊

■L

二I

CS的

鳴

謝\

.?一71

1.52004-08-28?根據網友審稿意見修改白楊

?在函數中增加“讓相同的

代碼只出現一次”的條目

?在區數頭中增加復雜性描

述

1.62004-11-22?修正了一些筆誤白楊

1.72005-03-30?新增成員函數的下劃線后白楊

綴命名

1.82005-05-04?小改動，修正了一些筆誤；白楊

在類命名規范中增加了界

面類的概念

1.92005-05-11?再次調整類命名規范，引入白楊

界面、類型和類的概念

1.102005-06-06?新增修改標記規則白楊

1.112005-06-07?新增類型和界面的使用策白楊

略

1.122005-06-28?修正一些筆誤白楊

1.132005-08-20?小幅修正和調整白楊

1.142005-11-08?對全文再次進行修正及調白楊

整

1.152005-11-14?增加數值前綴的特別記法白楊

1.162005-11-16?增加對復雜的宏實行縮進白楊

1.172005-11-21?補全修改標記規則白楊

?在常用注釋中增加一種新

型組注釋

1.182005-12-02?在文件頭中增加多線程和白楊

異常時安全性描述

1.192005-12-25?細化異常過濾器規則白楊CCF上

?增加特別代碼段注釋規則的網友,

特別感

謝

smartsl

1.202006-04-03?根據網友意見修正一些筆白楊

誤

1.212007-02-26?新增DUMMY表意宏白楊

1.222007-07-18白楊

?新增C++異常機制的實

現方式和開銷分析

1.232007-11-22.新增私有成員函數的層次白楊

結構表示

1.242008-01-17?措辭和表達上的細微調整白楊CCF上

的

Jiang

Haibin

1.252008-03-12?根據審稿人建議修正一些白楊

錯別字，感謝Haibin

兄：）

1.262008-06-26?新增“針對C程序員的快速白楊

回顧”一節

1.272008-07-27?修正一些錯別字白楊

1.282009-02-04?更新和一些小修正白楊

1.292009-03-31?新增函數對象的命名規則白楊

?新增OWNER表意宏對返回

值的修飾

1.302009-04-17?新增WRKBUF表意宏白楊

?新增new/delete時的異

常處理

1.312009-05-07白楊

?新增多處理器環境和線

程同步的高級話題

1.322010-06-14陸續對以下部分進行了一些更新白楊

和修正：

?RTTI、虛函數和虛基類的開

銷分析及使用指導

?多處理器環境和線程同步

的高級話題

?C++異常機制的實現方式和

開銷分析

1.332010-09-19?改善了代碼示例在IE7等白楊

新瀏覽器中的顯示錯位問

題。

目錄

?版權聲明

?fiM

.針對c程序員的快速回顧

?語法高亮與字體

O包

O語法高亮

.文件結構

O文件頭注釋

O頭文件

O內聯函數定義文件

O實現文件

o文件的組織結構

.命名規則

O類/結構

O函數

O變量

oW

O枚舉、聯合、typedef

o宏、枚舉值

O名空間

?代碼風格與版式

O類/結構

O函數

O變量、常量

O枚舉、聯合、typedef

o宏

o名空間

。維

O修改標記

?版本控制

?自動工具與文檔生成

?英文版

.關于本規范的要徹實施

.術語表

?參考文獻

?C++成長篇

?與我聯系

附件

?常用注釋一覽

?常用英文注釋一覽

?文件頭例子

?頭文件例子

?實現文件例

?內聯函數定義文件例子

?類/結構的風格與版式例子

?函數的風格4版式例子

?RTTI、虛函數和虛基類的實現方式、開銷分析和使用指導

.C++異常機制的實現方式和開銷分析

?多處理器環境和線程同步的高級話題

概述

對于任何工程項目來說，統一的施工標準都是保證工程質量的重要因素。堪

稱當今人類最抽象、最復雜的工程一一軟件工程，自然更加不能例外。

高品質、易維護的軟件開發離不開清晰嚴格的編碼規范。本文檔詳細描述C++

軟件開發過程中的編碼規范。本規范也適用于所有在文檔中出現的源碼。

除了“語法高亮”部分，本文檔中的編碼規范都以：

規則（或建議）解釋

的格式給出，其中強制性規則使用黑色，建議性規則使用灰色。

針對C程序員的快速回顧

本節旨在較高層面上快速回顧C與C++的主要區別。專門針對c思想根

深蒂固的老咖和經常需要在C/C++項目間頻繁切換的coderoC與C++

的主要區別包括：

?空參函數聲明的默認參數類型為void而不是int［編譯時］。

?強類型檢查和專門的類型轉換操作［編譯時，除dynamic_cast操

作］。

?名空間：用于歸類接口和模塊以及防止重名。名空間有自動向父級查

詢匹配和凱氏匹配。名空間的一個副作用是名稱粉碎，可以用extern

〃C〃聲明解決［編譯時］。

?類：類將一個C結構體和與之相關的函數打包在一起，并且提供了

編譯時的訪問控制檢查，為了擬真內置類型，還提供了操作符重載

［編譯時］。

?類層次結構：類可以通過相互間的繼承和派生形成層次結構，派生類

繼承了基類的數據結構和方法［編譯時］。

?模板：本質上是類型參數化。在編譯時生成C++代碼的過程叫做模

板實例化，默認的實例化點在當前編譯單元第一次使用該模板時，也

可以通過顯式實例化來增加編譯速度<>通過部分或完全的專門化可以

為指定類型提供優化算法［編譯時］。

?抽象類和虛方法:可以通過基類指針或引用訪問的動態重載技術［運

行時］。

?多重繼承和虛基類:一個類可以有多個父親，為了避免層次結構中出

現重復的基類，C++提供了虛基類［運行時］。

?運行時類型信息（RTTI）:允許程序員在類層次結構中漫游；完成動

態轉換（向上、向下和交叉強制）；獲取指定類型的typeid信息，

用戶可以以此為基礎實現反射、高級調試等各類功能。

?異常處理:本質上是一種安全的longjmp機制，在退棧期間能夠完

成必要的對象析構動作。主要用于在發生錯誤時跳轉到相應的錯誤處

理分支。

語法高亮與字體

字體

文字是信息的載體；文字使我們能夠把個人的經驗和思想長久的保存下來;

文字使我們得以站在前人的肩膀上向前發展；文字的誕生標志著人類文明

的開始……

扯的太離譜了？好吧，至少你應該承認:

?沒有文字就不可能出現計算機（先不管他是哪國字）

.沒有文字大家就不可能（也沒必要）學會如何寫程序

?在過去、現在和可見的將來，使用文字符號都是編寫計算機軟件的

主要方式方法

既然文字如此重要，它的長相自然會受到廣泛的關注。如今這個連MM都可

以“千面”的年頭，字體的種類當然是數不勝數。

然而，前輩先賢們曾經用篆體教導偶們：。

想讓大家讀到縮進、對齊正確一致，而且不出現亂碼的源文件，我們就要

使用相互兼容的字體。

字體規范如下:

使用等寬字體由于非等寬字體在對齊等方面問題多多，任

何情況下，源碼都必須使用等寬字體編輯和

顯示。

每個制表符（TAB）的寬不一致的縮進寬度會導致行與行之間的參

度為4個半角字符差不齊，進而嚴重影響代碼的可讀性。

優先使用Fixedsys在Windows平臺中，應該優先使用字體：

Fixedsys,這也是操作系統UI（所有的菜單、

按鈕、標題欄、對話框等等）默認使用的字

體。該字體的好處很多：

?兼容性好：所有Windows平臺都支持

該字體

?顯示清晰：該字體為點陣字體，相對

于矢量字體來說在顯示器中呈現的

影像更為清晰。矢量字體雖然可以自

由縮放，但這個功能對于純文本格式

的程序源碼來說沒有任何實際作用。

而且當顯示字號較小（12pt以下）時，

矢量字體還有二些明顯的缺陷：

O文字的邊緣會有嚴重的凹凸

感。

O一些筆畫的比例也會失調。

O開啟了柔化字體邊緣后，還會

使文字顯得模糊不清。

說句題外話,這也是Gnome和KDE等

其它GUI環境不如Windows的一個重

要方面（2009年更新：現如今這些

環境的界面和字體也不比Windows

差了）。

?支持多語言：Fixcdsys可以兼容其它

UNICODE等寬字體，所以支持世界上

幾乎所有的文字符號。這對編寫中文

注釋是很方便的。

語法高亮

幾乎所有的現代源碼編輯器均不同在程度上支持語法高亮顯示的功能。繽

紛的色彩不但可以吸引MM們的目光，還可以在很大程度上幫助我們閱讀那

些奧澀如咒語般的源代碼。

統一的語法高亮規則不僅能讓我們望色生意，還可以幫助我們閱讀沒有編

碼規范，或者規范執行很爛的源碼。

所有在文檔中出現的代碼段均必須嚴格符合下表定義的語法高亮規范。在

編輯源碼時，應該根據編輯器支持的自定義選項最大限度地滿足下表定義

的高亮規范。

類型顏色舉例

注釋//注釋例子

R0;G128;B0（深綠）

關鍵字typedef,int,

R0;G0;B255（藍）

dynamic_cast

class...

類、結構、聯合、枚class

R0;G0;B255（藍）

舉等其它自定義類型CMyClass,

enum

ERRTYPE,

lypedefint

CODE...

名空間namespace

R0;G0;B255（藍）

BaiY

數字012119u

R255;G0;B0（紅）

Oxff...

字符、字符串"string",'c...

R0;G128;B128（深藍綠）

宏定義、枚舉值#define

R255;G128;B0（橙黃）

UNICODE,

cnum{RED,

GREEN,

BLUE};

操作符<>,=+-*/;

R136;G0;B0（棕色）

{}（）[]...

方法/函數MyFunc（）

R136;G0;B0（棕色）

變量intnMyVar;

R128;G128;B128（中灰色）

背景

R255;G255;B255（白色）

其它otherthings

RO;GO;BO（黑色）

（通常是一

個錯誤）

文件結構

文件頭注釋

所有C++的源文件均必須包含一個規范的文件頭，文件頭包含了該文件的名稱、

功能概述、作者、版權和版本歷史信息等內容。標準文件頭的格式為:

/*!?file

*1**1**1**1?*)?***J**1**1**(?*J?*?*|?*?■J*?*J**j**j**S

*Y*f4、*7**1*

＜PRE＞

模塊名:〈文件所屬的模塊名稱》

文件名:〈文件名〉

相關文件：〈與此文件相關的其它文件＞

文件實現功能：〈描述該文件實現的主要功能》

作者:〈作者部門和姓名〉

版本:〈當前版本號》

多線程安全性：＜是/否＞[,說明]

異常時安全性：＜是/否＞[,說明]

備注:〈其它說明》

修改記錄：

日期版本修改

人修改內容

YYYY/MM/DDX.Y〈作者或修改者名）〈修改內容）

</PRE>

*1*

*1**1**1****1**j?*j?*s*1**j**s

/

*1*(

如果該文件有其它需要說明的地方，還可以專門為此擴展一節，節與節之間用

長度為80的“二"帶分割：

/*!@file

*{*xx*J**{**J*x*3**5*

＜PRE＞

模塊名：〈文件所屬的模塊名稱》

文件名?〈文件名〉

相關文件：〈與此文件相關的其它文件＞

文件實現功能：〈描述該文件實現的主要功能》

作者:〈作者部門和姓名）

版本:〈當前版本號）

多線程安全性：<是/否>［,說明］

異常時安全性：〈是/否"，說明］

備注：〈其它說明》

修改記錄：

日期版本修改

人修改內容

YYYY/MM/DDX.Y〈作者或修改者名〉〈修改內容》

</PRE>

xjcX*^Cxjc5^C5Jc*gCxjc5J%5^C5^C*^C5^C*^C*gC

KW*A*?,

*T*^7^*1**T**T**?*

*項

gl

項

目11

一A

項012

一1

*項目2

-項目2.1

項目2.2

K1**XX7,xl*?/x?lxxi*xl**A^?￡x*1**1*xlzxi*v^z?lx*1*?Jx*1**1*vS*?2x?2xxl*KIZ?2X?X*xl*?Jx

*Y?，「4、*Y?，5。、4、*IS*J*，,、4、*T*，＞，,、＜、*?*.、，＞4、*i*，卜，,、*(?*Y*，門4、*?**T*，,、4、*Y?。、4、*Y*.、，.、4、*,*，卜，,、4、4、*T*，.、4、*T*，卜，,、4、*T*，^q、.、，*、

、1,*L?■],、1，*1*^1**2^、[*^L?/

^T*/

每行注釋的長度都不應該超過80個半角字符。還要注意縮進和對齊，以利閱讀。

注意：將多線程和異營時安全性描述放在文件頭，而不是類或者函數注釋口，

是為了體現以下設計思想：同一個模塊中的界面，其各方面的操作方式和使用

風格應該盡量保持一致。

關于文件頭的完整例子，請參見：文件頭例子

關于文件頭的模板，請參見：文件頭注釋模板

頭文件

頭文件通常由以下幾部分組成:

文件頭注釋每個頭文件，無論是內部的還是外部的，都

應該由一個規范的文件頭注釋作為開始。

預處理塊為了防止頭文件被重復引用，應當用

ifndef/define/endif結構產生預處理塊。

函數和類/結構的聲明等聲明模塊的接口

需要包含的內聯函數定如果類中的內聯函數較多，或者一個頭文件

義文件（如果有的話）中包含多個類的定義（不推薦），可以將所

有內聯函數定義放入一個單獨的內聯函數

定義文件中,并在類聲明之后用

/include”指令把它包含進來。

頭文件的編碼規則:

引用文件的格式用#include^filename.h＞格式來引用標

準庫和系統庫的頭文件（編譯器將從標準庫

目錄開始搜索）。

用tfinclude^filename,h*格式來引用當

前工程中的頭文件（編譯器將從該文件所在

目錄開始搜索）。

分割多組接口（如果有的如果在一個頭件中定義了多個類或者多組

話）接口（不推薦），為了便于瀏覽，應該在每

個類/每組接口間使用分割帶把它們相互分

開。

關于頭文件的完整例子，請參見：頭文件例子

內聯函數定義文件

如上所述，在內聯函數較多的情況下，為了避免頭文件過長、版面混亂，

可以將所有的內聯函數定義移到一個單獨的文件中去，然后再用#5。1皿2

指令將它包含到類聲明的后面。這樣的文件稱為一個內聯函數定義文件。

按照慣例，應該將這個文件命名為,其中“filename”

與相應的頭文件和實現文件相同。

內聯函數定義文件由以下兒部分組成：

文件頭注釋每內聯函數定義文件都應該由一個規范的

文件頭注釋作為開始

內聯函數定義內聯函數的實現體

內聯函數定義文件的編碼規則:

分割多組接口（如果有的如果在一個內聯函數定義文件中定義了多

話）個類或者多組接口的內聯函數（不推薦），

必須在每個類/每組接口間使用分割帶把它

們相互分開。

文件組成中為什么沒有與頭文件不同，內聯函數定義文件通常不需

預處理塊？要定義預處理塊，這是因為他們總是被包含

在與其相應的頭文件預處理塊內。

關于內聯函數定義文件的完整例子，請參見：內聯函數定義文件例子

實現文件

實現文件包含所有數據和代碼的實現體。實現文件的格式為:

文件頭注釋每個實現文件都應該由一個規范的文件頭

注釋作為開始

對配套頭文件的引用引用聲明了此文件實現的類、函數及數據的

頭文件

對一些僅用于實現的頭將僅與實現相關的接口包含在實現文件里

文件的引用（如果有的（而不是頭文件中）是一個非常好的編程習

話）慣。這樣可以有效地屏蔽不應該暴露的實現

細節，將實現改變對其它模塊的影響降低到

最少。

程序的實現體數據和函數的定義

實現文件的編碼規則:

分割每個部分在本地（靜態）定義和外部定義問，以及不

同接口或不同類的實現之間，應使用分割帶

相互分開。

關于實現文件的完整例子，請參見：實現文件例子

文件的組織結構

由于項目性質、規模上存在著差異，不同項目間的文件組織形式差別很大。

但文件、目錄組織的基本原則應當是一致的：使外部接口與內部實現盡量

分離；盡可能清晰地表達軟件的層次結構……

為此提供兩組典型項目的文件組織結構范例作為參考：

功能模塊/庫的文件組織形式

顯而易見，編寫功能模塊和庫的主要目的是為其它模塊提供一套

完成特定功能的API,這類項目的文件組織結構通常如下圖所示:

其中:

contrib當前項目所依賴的所有第三方軟

件，可以按類別分設子目錄。

doc項目文檔

include聲明外部接口的所有頭文件和內

聯定義文件。

lib編譯好的二進制庫文件，可以按編

譯器、平臺分設子目錄。

makefile用于編譯項目的makefile文件和

project文件等。可以按編譯器、

平臺分設子目錄。

src所有實現文件和聲明內部接口的

頭文件、內聯定義文件。可按功能

劃分；支持編譯器、平臺等類別分

設子目錄。

test存放測試用代碼的目錄。

應用程序的文件組織形式

與功能模塊不同，應用程序是一個交付給最終用于使用的、可以

獨立運行并提供完整功能的軟件產品，它通常不提供編程接口，

應用程序的典型文件組織形式如下圖所示：

contrib當前項目所依賴的所有第二方軟

件，可以按類別分設子目錄。

doc項目文檔

makefile用于編譯項目的makefile文件和

project文件等。可以按編譯器、

平臺分設子目錄。

setup安裝程序，以及制作安裝程序所需

要的項目文件和角木。

src所有源文件。可按功能劃分；支持

編譯器、平臺等類別分設子目錄。

test存放測試用代碼的目錄。

命名規則

如果想要有效的管理一個稍微復雜一點的體系，針對其中事物的一套統一、帶層

次結構、清晰明了的命名準則就是必不可少而且非常好用的工具。

活躍在生物學、化學、軍隊、監獄、黑社會、恐怖組織等各個領域內的大量有識

先輩們都曾經無數次地以實際行動證明了以上公理的正確性。除了上帝（設它可

以改變世間萬物的秩序）以外，相信沒人有實力對它不屑一顧

在軟件開發這一高度抽象而且十分復雜的活動中，命名規則的重要性更顯得尤為

突出C一套定義良好并且完整的、在整個項目中統一使用的命名規范將大大提升

源代碼的可讀性和軟件的可維護性。

在引入細節之前，先說明一下命名規范的整體原則:

同一性在編寫一個子模塊或派生類的時候，要遵循其基

類或整體模塊的命名風格，保持命名風格在整個

模塊中的同一性。

標識符組成標識符采用英文單詞或其組合，應當直觀且可以

拼讀，可望文知意，用詞應當準確。

最小化長度&&最大化在保持一個標識符意思明確的同時，應當盡量縮

信息量原則短其長度。

避免過于相似不要出現僅靠大小寫區分的相似的標識符，例如

“i”與"I","function"與"Function”等

等。

避免在不同級別的作用程序中不要出現名字完全相同的局部變量和全

域中重名局變量，盡管兩者的作用域不同而不會發生語法

錯誤，但容易使人誤解。

正確命名具有互斥意義用正確的反義詞組命名具有互斥意義的標識符，

的標識符如:"nMinValue"和"nMaxValue","GetNameO"

和"SetName（）〃....

避免名字中出現數字編盡量避免名字中出現數字編號，如

號Valuel,Value2等，除非邏輯上的確需要編號。

這是為了防止程序員偷懶，不肯為命名動腦筋而

導致產生無意義的名字（因為用數字編號最省

事）。

類/結構

除了異常類等個別情況（不希望被用戶看作一個普通的、正常的類之情況）

外，C++類/結構的命名應該遵循以下準則：

C++類/結構的命名類的名稱都要以大寫字母“C”開頭，后跟

一個或多個單詞。為便于界定，每個單詞的

首字母要大寫。

特別地，由于界面與其它類概念上的巨大差

別，規定界面類要以大寫字母“I”開頭。

界面類描述一個服務（一組被命名的操作集

合），在C++中，界面與其它類間的最大

區別在于，界面類中不包含任何數據結構

（屬性），也不包括任何具體的操作和實現,

界面類通常僅包含一組純虛函數的聲明而

不包含任何實現和數據。在一些其它語言

中，一個界面也被稱作一個接口及其實現契

約。

另一個與接口相似的概念是類型，類型與接

口的不同點在于，類型可以包含部分接口的

實現或包含一些接口默認的或不完整的實

現，一個類型也可以包含一些屬性。規定類

型類要以大寫字母開頭。例如：轎車

類型〃TCar〃、線程類型〃TThread〃等等。

在C++種，類型類也叫做結點類。

在現實世界中，類型和界面的區別往往比較

微妙。在真實代碼中，有些類除了包含純虛

函數以外，也可能同時包含幾個帶簡單默認

實現的普通虛函數。例如：某個類中可能包

含一個（非純虛）虛方法IsLoadable,并

定義了該方法的默認實現：returnfalser

我們不難找出很多類似的例子。

以下是一些類型和界面的界定策略：

?如果一個類中包含靜態成員，則一定

不是界面

.如果一個類中包含屬性，則一定不是

界面

?如果一個類中包含非虛方法，則一定

不是界面

?如果一個類中包含非公有成員，則一

定不是界面

?如果一個類中包含模板方法，則一定

不是界面。

這里的模板方法是指那些調用了該

類中其它虛函數的成員，這樣的方法

通常用于實現針對某種應用的算法

框架，這顯然超出了界面的范疇。

在C++中，模板方法的另一個意思

通常指使用函數模板的成員，由于C

++函數模板只能是非虛的，所以包

含這種方法的類也一定不是界面。

?通常定義那些不十分明確的接口時，

先將其指定為一個界面，必要時再把

它提升為一個類型。

模板類的命名規范與實體類相同。

為了更好地表示代碼段之間的相關性和增

加程序的可讀性。我們經常會把一段僅在某

個函數內反復使用的代碼片段封裝為一個

函數對象，并定義在這個函數體內。對于

這類實現功能簡單，并且主要通過

operator()來使用的類/結構，其名稱應當

以大寫字母"F0”開頭，如：

〃FONameChecker〃等。

推薦的組成形式類的命名推薦用〃名詞〃或〃形容詞+名詞〃

的形式，例如："CAnalyzer",

〃CFas(Vector","IUnknown”,

"IDBWriter","TTimer",，，TThread，z....

不同于C++類的概念，傳統的C結構體只是一種將一組數據捆綁在一起的方

式。傳統C結構體的命名規則為：

傳統C結構體的命名傳統C結構體的名稱全部由大寫字母組成,

單詞間使用下劃線界定，例如：

〃SERVICE_STATUS","DRIVER_INFO/，....

函數

函數的命名函數的名稱由一個或多個單詞組成。為便于

界定，每個單詞的首字母要大寫。

推薦的組成形式函數名應當使用〃動詞〃或者〃動詞+名詞〃

(動賓詞組)的形式。例如：〃GetName()〃,

“SetValue()”,"Erase()〃，

“Reserve。”.…

保護成員函數保護成員函數的開頭應當加上一個下劃線

以示區別，例如：

私有成員函數類似地，私有成員函數的開頭應當加上兩個

下劃線，例如：

〃―DestroylmpO，?....

私有成員函數的層次結通常來說，在一個類中，公有方法、保護方

構表示法和私有方法所完成的任務總是呈現一種

逐級依次細化的層次結構（意即：保護方法

所實現的功能通常比該類中的公有方法更

為細小瑣碎；類似地，私有方法的功能也比

其保護方法更具原子性）。

因此，對于遵循以上規則，并且功能較為復

雜的類，在按照“公有、保護、私有”的三

級形式劃分以后，如果其私有成員中仍然存

在明顯不同的功能粒度，則可以通過追加更

多下劃線前綴的形式予以表示。

例如：由三個下劃線開頭的私有方法

“—PushCdr”就要比同一類中，僅由兩個

下劃線開頭的私有方法

<<_MergeConCair,所完成的功能粒度更

細小、更瑣碎；而四個下劃線開頭的

CalcCompensate”則比

“_PushCdr”完成的功能更具原子性。

如果發現類中的功能層數太多（從公有方法

到最“原子”的私有方法間，一般不應該超

過7層），那通常反應一個不良的設計。

此時請檢查這個類的功能是否過于臃腫，已

使接口顯得不太清晰。另外一個常見的問題

是將無需訪問該類中私有或保護成員的功

能定義成了方法。第一個問題可以通過重新

劃分類層次結構或將一個類分裂為多個類

等方法解決。對于第二個問題，由于這些方

法無需訪問受限成員，大多數時候都可以

把它們轉變成局部函數（放在無名空間或使

用“static”前綴定義）。

成員函數的下劃線后綴對一些本應該作為保護或私有成員的函數，

命名由丁?設計方面的其它考慮（例如：靈活性、

功能等方面）將其提升為公有成員的，應該

在其后面添加與其原本訪問控制級別相應

的下劃線后綴。

另外，對于其它不推薦直接使用的成員函數

（例如：會引起兼容性或可移植性方面問題

的函數），也應當在其后面加相應下劃線提

示。

例如：〃ioctLO",〃SetSysOpt_()〃，

〃GetSysOpt_()","PreParser—

回調和事件處理函數回調和事件處理函數習慣以單詞“On”開

頭。例如：〃OnTimer()〃，“OnExit()〃....

虛函數回調函數以外的虛函數習慣以“Do”開頭，

如："DoKefreshO",

z，DoEncryption()〃....

變量

變量應該是程序中使用最多的標識符了，變量的命名規范可能是一套C++

命名準則中最重要的部分：

變量的命