1. 程式人生 > >Google C++程式碼風格指南翻譯簡化版(google c++ code style guide)【七】

Google C++程式碼風格指南翻譯簡化版(google c++ code style guide)【七】

本文件基於網上流傳的Google C++程式設計風格指南,由 edisonpeng(2009/3/25)整理

本地化簡化由MISAS開發團隊使用。在此分享以供各開發團隊參考。

目錄

格式化

MISAS開發團隊的C++開發規範約定,1個Tab=4個空格

行長度

每一行字元數不超過80

這一條存在例外情況:

(1)如果一行註釋包含了超過80字元的命令或URL,出於複製貼上方便可以超過80字元;

(2)包含長路徑的可以超過80列,儘量避免

(3)標頭檔案保護可以無視該原則

非ASCII字元

儘量不使用ASCII字元,使用時必須使用UTF-8格式

空格 or 製表符Tab

只使用Tab,約定Tab長度為4個空格

函式宣告與定義

返回型別和函式名在同一行,引數也在同一行。

如果一行文字較多寫不下所有引數,則引數換行Tab對齊:

ReturnType LongClassName::ReallyReallyReallyLongFunctionName(
    Type par_name1,
    Type par_name2,
    Type par_name3) 
{
    DoSomething(); // 2 space indent
    ...
}

注意:
(1)返回值和函式在同一行

(2)左圓括號(總是和函式名在同一行

(3)函式名和左圓括號之間沒有空格

(4)圓括號與引數沒有空格

(5)函式的左花括號另起一行,單獨置於一行

(6)函式的右花括號在函式最後,單獨置於一行

(7)右圓括號和左花括號間換行

(8)函式宣告和實現處的所有形參名稱必須保持一致

(9)所有形參儘可能對齊

(10)預設縮排為1個Tab,即4個空格

(11)獨立封裝的引數保持4個空格縮排

const函式,關鍵字const和最後一個引數置於同一行

ReturnType LongClassName::ReallyReallyReallyLongFunctionName(
    Type par_name1,
    Type par_name2,
    Type par_name3) const
{
    DoSomething(); // 2
space indent ... }

用不到的引數需在函式的註釋中說明

函式呼叫

儘量放在同一行,否則將括號內的引數換行對齊

條件語句

條件語句的左花括號放在條件語句的行位,格式上與函式區分

注意:條件內哪怕只有一行語句,也要寫全花括號,方便後續運維。

有些條件語句寫在一行可以增強可讀性,僅當語句簡單且沒有else子句時可以使用:

if (x == kFoo) return new Foo();
if (x == kBar) return new Bar();

注意:如果有else子句,則禁止不帶花括號。

迴圈和開關選擇語句(loop and switch)

switch 語句儘量使用大括號分塊

switch 語句必須要有default存在,如正常不會執行則以異常日誌或控制檯資訊的方式處理。

空迴圈使用{}或者continue,禁止迴圈只用一個分號

指標和引用表示式

句點(.)、箭頭(->)前後不要有空格,指標(*)、地址操作符(&)後不要有空格

value = *test;
value = &test;
value = c.test;
value = c->test;

char *cinput;
const string &str_name;

布林表示式

如果布林表示式超過標準行寬(80字元),則斷行且要求邏輯操作符置於行尾。

if (this_one_thing > this_other_thing   &&
    a_third_thing == a_fourth_thing     &&
    yet_another & last_one) {
    ...
}

有多個邏輯操作符時,考慮使用圓括號()提示運算優先順序

返回值

函式返回(即:return 表示式)時不要使用圓括號。

初始化操作

使用等號(=)完成

預處理

不要縮排,從行首開始。及時在縮排程式碼塊中,也要從行首開始。

類格式

類格式參考本規範第三篇宣告次序章節。

初始化列表

初始化列表置於同一行,或換行Tab補齊

名稱空間格式化

名稱空間內容不縮排。

水平空白

行尾不要增加無意義的空白。當行尾有註釋需要Tab補齊時可以適當留空。

垂直空白

垂直空白儘量少。函式之間、模組之間留一樣空白

規則之例外

前文提到的編碼習慣基本是強制性的,但優秀的規則都允許例外。

現有不統一程式碼

現有成熟的工程不符合既定規範可以網開一面,2018年起自主開發的工程後續逐步修正。

Windows程式碼

在Windows平臺開發,除系統API不能更改外,自主開發內容需遵循本規則。

團隊合作

團隊風格一致性,程式碼高可讀性。