Google C++ 编码风格精简
? Google C++?編碼風格精簡
頭文件：
1.頭文件防多重定義define格式：<PROJECT>_<PATH>_<FILE>_H_
2.能使用前置聲明盡量不用頭文件包含
3.只有當函數只有?10?行甚至更少時才將其定義為內聯函數（注意虛函數，遞歸函數，以及使用了循環語句的函數）
4.復雜的內聯函數的定義,?放在后綴名為?-inl.h?的頭文件中
5.定義函數時，輸入參數永遠放在輸出參數之前
6.項目內頭文件應按照項目源代碼目錄樹結構排列
7.example.cc包含頭文件順序：example.h,C系統文件,C++?系統文件,其他庫的h文件,本項目內h文件
?
?
作用域：
1.在.cc文件中,?允許甚至鼓勵使用匿名名字空間;不要在h文件中使用匿名名字空間?
2.在.cc文件.h文件的函數,?方法或類中,?可以使用?"using"關鍵字?及?名字空間別名?
3.不要將嵌套類定義成公有,?除非它們是接口的一部分,?比如,?嵌套類含有某些方法的一組選項
4.使用靜態成員函數或名字空間內的非成員函數,?盡量不要用裸的全局函數?
5.將函數變量盡可能置于最小作用域內,?并在變量聲明時進行初始化
6.禁止使用?class?類型的靜態或全局變量:?它們會導致很難發現的?bug?和不確定的構造和析構函數調用順序
?
?
類：
1.構造函數中只進行那些沒什么意義的初始化,?可能的話,?使用?Init()?方法集中初始化有意義的數據
2.如果一個類定義了若干成員變量又沒有其它構造函數,?必須定義一個默認構造函數
3.對單個參數的構造函數使用?C++?關鍵字?explicit（如果構造函數只有一個參數,?可看成是一種隱式轉換）
4.僅在代碼中需要拷貝一個類對象的時候使用拷貝構造函數;?大部分情況下都不需要,?此時應使用?DISALLOW_COPY_AND_ASSIGN
{
#define?DISALLOW_COPY_AND_ASSIGN(TypeName)?/
TypeName(const?TypeName&);?/
void?operator=(const?TypeName&)
}
5.僅當只有數據時使用?struct,?其它一概使用?class
6.使用組合常常比使用繼承更合理.?如果使用繼承的話,?定義為?public?繼承
7.如果你的類有虛函數,?則析構函數也應該為虛函數
8.當重載一個虛函數,?在衍生類中把它明確的聲明為?virtual
9.只在以下情況我們才允許多重繼承:?最多只有一個基類是非抽象類;?其它基類都是以Interface為后綴的純接口類
10.接口是指滿足特定條件的類,?這些類以?Interface?為后綴?(不強制).
11.盡量不要重載運算符
12.數據成員在任何情況下都必須是私有的,?并根據需要提供相應的存取函數
13.在類中使用特定的聲明順序:?public:?在?private:?之前,?成員函數在數據成員前
14.如果函數超過?40?行,?可以思索一下能不能在不影響程序結構的前提下對其進行分割
?
Google奇技：
1.盡量避免使用智能指針（任何情況下都不要使用?auto_ptr）,使用時也盡量局部化
2.使用?cpplint.py?檢查風格錯誤
?
C++特性：
1.?輸入參數是值參或?const?引用,?輸出參數為指針.
2.僅在輸入參數類型不同,?功能相同時使用重載函數?(含構造函數)
3.不允許使用缺省函數參數
4.不允許使用變長數組和?alloca()
5.不要在?Google?的開源項目中使用異常（關于這一點google僅僅是為了自身方便=。=）
6.禁止使用RTTI
7.使用?C++?的類型轉換,?如?static_cast<>().?不要使用?int?y?=?(int)x?或?int?y?=?int(x)?等轉換方式
{
用?static_cast?替代?C?風格的值轉換,?或某個類指針需要明確的向上轉換為父類指針時
用?const_cast?去掉?const?限定符
用?reinterpret_cast?指針類型和整型或其它指針之間進行不安全的相互轉換.?僅在你對所做一切了然于心時使用?dynamic_cast?測試代碼以外不要使用.?除非是單元測試,?如果你需要在運行時確定類型信息,?說明有?設計缺陷
}
8.只在記錄日志時使用流
9.對迭代器和模板類型,?使用前置自增?(自減).對簡單數值?(非對象)無所謂
10.強烈建議你在任何可能的情況下都要使用?const
{
如果函數不會修改傳入的引用或指針類型參數,?該參數應聲明為?const.
盡可能將函數聲明為?const.?訪問函數應該總是?const.?其他不會修改任何數據成員,?未調用非?const?函數,?不會返回數據成員非?const?指針或引用的函數也應該聲明成?const.
如果數據成員在對象構造之后不再發生變化,?可將其定義為?const.
}
11.C++?內建整型中,?僅使用?int.?如果程序中需要不同大小的變量,?可以使用?<stdint.h>?中長度精確的整型,?如?int16_t
12.使用斷言來指出變量為非負數,?而不是使用無符號型
13.代碼應該對?64?位和?32?位系統友好（！！！）
14.使用宏時要非常謹慎,?盡量以內聯函數,?枚舉和常量代替之
{
不要在?.h?文件中定義宏
在馬上要使用時才進行?#define,?使用后要立即?#undef
不要只是對已經存在的宏使用#undef，選擇一個不會沖突的名稱
不要試圖使用展開后會導致?C++?構造不穩定的宏,?不然也至少要附上文檔說明其行為
}
15.整數用?0,?實數用?0.0,?指針用?NULL,?字符?(串)?用?'/0'
16.盡可能用?sizeof(varname)?代替?sizeof(type)
17.只使用?Boost?中被認可的庫
?
命名約定：
1.函數命名,?變量命名,?文件命名應具備描述性;?不要過度縮寫.?類型和變量應該是名詞,?函數名可以用?“命令性”?動詞
2.文件名要全部小寫,?可以包含下劃線?(_)?或連字符?(-).?按項目約定來.
3.類型名稱的每個單詞首字母均大寫,?不包含下劃線:?MyExcitingClass,?MyExcitingEnum.
4.變量名一律小寫,?單詞之間用下劃線連接.?類的成員變量以下劃線結尾:my_local_variable,my_member_variable_
5.結構體的數據成員可以和普通變量一樣,?不用像類那樣接下劃線
6.常量命名?在名稱前加?k,接大寫字母開頭的單詞
7.函數名的每個單詞首字母大寫,?沒有下劃線,取值和設值函數要與存取的變量名匹配.非常短小的內聯函數名也可以用小寫字母
8.名字空間用小寫字母命名,?并基于項目名稱和目錄結構:?google_awesome_project.
9.枚舉的命名應當和常量一致:?kEnumName.
?
?
代碼注釋：
1.使用行注釋或塊注釋，統一就好
2.在每一個文件開頭加入版權公告，然后是文件內容描述
{
版權；
許可版本:Apache2.0?BSD?LGPL?GPL；
作者；
文件內容
}
3.每個類的定義要附著類的功能和用法的注釋
4.函數聲明處注釋描述函數功能，定義處描述函數實現
5.類數據成員應注釋說明用途，是否可以接受NULL或-1等警戒值
6.全局變量注釋說明含義和用途
7.復雜代碼前要加注釋；比較隱晦的代碼后空兩格加行尾注釋
8.向函數傳入整型，布爾值和指針時，注釋說明含義，或使用常量讓代碼望文知意
9.臨時，短期，或不夠完美的解決方案使用TODO注釋；格式//TODO（ID）：Information
?
?
格式：
1.每一行長度不要超過80（路徑，URL，頭文件保護除外）
2.盡量不使用非ASCII字符，使用時必須使用UTF-8字符
3.只使用空格，每次縮進兩個空格
4.函數聲明：返回值和函數名在同一行，參數也盡量放在同一行
{
返回值總是和函數名在同一行；
左圓括號總是和函數名在同一行；
函數名和左圓括號間沒有空格
圓括號與參數間沒有空格；
左大括號總在最后一個參數同一行的末尾處?；
右大括號總是單獨位于函數最后一行；
右圓括號和左大括號間總是有一個空格；
函數聲明和實現處的所有形參名稱必須保持一致；
所有形參應盡可能對齊；
缺省縮進為2個空格；
換行后的參數保持4個空格的縮進；
}
5.如果函數聲明成const，關鍵字const應與最后一個參數位于同一行?
6.如果有些參數沒有用到,?在函數定義處將參數名注釋起來
7.函數調用盡量放在同一行,?否則,?將實參封裝在圓括號中
8.switch?語句可以使用大括號分段.?空循環體應使用?{}?或?continue.?
9.如果一個布爾表達式超過標準行寬斷行方式要統一
10.return?表達式中不要用圓括號包圍
11.預處理指令不要縮進,?從行首開始?
12.訪問控制塊的聲明依次序是?public:,?protected:,?private:,?每次縮進?1?個空格?
13.構造函數初始化列表放在同一行或按四格縮進并排幾行
14.名字空間內容不增加縮進層次
15.永遠不要在行尾添加沒意義的留白
16.不在萬不得已,?不要使用空行.?尤其是:?兩個函數定義之間的空行不要超過?2?行,?函數體首尾不要留空行,?函數體中也不要隨意添加空行?
?
?
規則特例：
對于Windows程序員：
1.不要使用匈牙利命名法,使用?Google?命名約定,?包括對源文件使用?.cc?擴展名
2.盡量使用原有的?C++?類型?
3.使用?Microsoft?Visual?C++?進行編譯時,?將警告級別設置為?3?或更高,?并將所有?warnings?當作?errors?處理?
4.不要使用?#pragma?once;?而應該使用?Google?的頭文件保護規則?
5.除非萬不得已,?不要使用任何非標準的擴展,?
總結
以上是生活随笔為你收集整理的Google C++ 编码风格精简的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： IOC注解注入View
- 下一篇： java HelloWorld 编程风格