https://google-styleguide.readthedocs.io/zh_CN/latest/google-cpp-styleguide/headers.html#self-contained

頭文件相關?

?1.4內聯函數

定義:

當函數被聲明為內聯函數之后, 編譯器會將其內聯展開, 而不是按通常的函數調用機制進行調用.

優點:

只要內聯的函數體較小, 內聯該函數可以令目標代碼更加高效. 對于存取函數以及其它函數體比較短, 性能關鍵的函數, 鼓勵使用內聯.

缺點:

濫用內聯將導致程序變得更慢. 內聯可能使目標代碼量或增或減, 這取決于內聯函數的大小. 內聯非常短小的存取函數通常會減少代碼大小, 但內聯一個相當大的函數將戲劇性的增加代碼大小. 現代處理器由于更好的利用了指令緩存, 小巧的代碼往往執行更快。

結論:

一個較為合理的經驗準則是, 不要內聯超過 10 行的函數. 謹慎對待析構函數, 析構函數往往比其表面看起來要更長, 因為有隱含的成員和基類析構函數被調用!

另一個實用的經驗準則: 內聯那些包含循環或?switch?語句的函數常常是得不償失 (除非在大多數情況下, 這些循環或?switch?語句從不被執行).

有些函數即使聲明為內聯的也不一定會被編譯器內聯, 這點很重要; 比如虛函數和遞歸函數就不會被正常內聯. 通常, 遞歸函數不應該聲明成內聯函數.（YuleFox 注: 遞歸調用堆棧的展開并不像循環那么簡單, 比如遞歸層數在編譯時可能是未知的, 大多數編譯器都不支持內聯遞歸函數). 虛函數內聯的主要原因則是想把它的函數體放在類定義內, 為了圖個方便, 抑或是當作文檔描述其行為, 比如精短的存取函數.

1.5.?#include?的路徑及順序?

使用標準的頭文件包含順序可增強可讀性, 避免隱藏依賴: 相關頭文件, C 庫, C++ 庫, 其他庫的?.h, 本項目內的?.h.

項目內頭文件應按照項目源代碼目錄樹結構排列, 避免使用 UNIX 特殊的快捷目錄?.?(當前目錄) 或?..?(上級目錄). 例如,?google-awesome-project/src/base/logging.h?應該按如下方式包含:

#include "base/logging.h"

又如,?dir/foo.cc?或?dir/foo_test.cc?的主要作用是實現或測試?dir2/foo2.h?的功能,?foo.cc?中包含頭文件的次序如下:

dir2/foo2.h?(優先位置, 詳情如下)

C 系統文件

C++ 系統文件

其他庫的?.h?文件

本項目內?.h?文件

這種優先的順序排序保證當?dir2/foo2.h?遺漏某些必要的庫時，?dir/foo.cc?或?dir/foo_test.cc?的構建會立刻中止。因此這一條規則保證維護這些文件的人們首先看到構建中止的消息而不是維護其他包的人們。

作用域相關

?2.1. 命名空間

小技巧

鼓勵在?.cc?文件內使用匿名命名空間或?static?聲明. 使用具名的命名空間時, 其名稱可基于項目名或相對路徑. 禁止使用 using 指示（using-directive）。禁止使用內聯命名空間（inline namespace）。

定義:

命名空間將全局作用域細分為獨立的, 具名的作用域, 可有效防止全局作用域的命名沖突.

優點:

雖然類已經提供了（可嵌套的）命名軸線 (YuleFox 注: 將命名分割在不同類的作用域內), 命名空間在這基礎上又封裝了一層.

舉例來說, 兩個不同項目的全局作用域都有一個類?Foo, 這樣在編譯或運行時造成沖突. 如果每個項目將代碼置于不同命名空間中,?project1::Foo?和?project2::Foo?作為不同符號自然不會沖突.

內聯命名空間會自動把內部的標識符放到外層作用域，比如：

namespace X { inline namespace Y { void foo(); } // namespace Y } // namespace X

X::Y::foo()?與?X::foo()?彼此可代替。內聯命名空間主要用來保持跨版本的 ABI 兼容性。

缺點:

命名空間具有迷惑性, 因為它們使得區分兩個相同命名所指代的定義更加困難。

內聯命名空間很容易令人迷惑，畢竟其內部的成員不再受其聲明所在命名空間的限制。內聯命名空間只在大型版本控制里有用。

有時候不得不多次引用某個定義在許多嵌套命名空間里的實體，使用完整的命名空間會導致代碼的冗長。

在頭文件中使用匿名空間導致違背 C++ 的唯一定義原則 (One Definition Rule (ODR)).

7.4. 變量命名?

?總述

變量 (包括函數參數) 和數據成員名一律小寫, 單詞之間用下劃線連接. 類的成員變量以下劃線結尾, 但結構體的就不用, 如:?a_local_variable,?a_struct_data_member,?a_class_data_member_.

?7.6. 函數命名

總述

常規函數使用大小寫混合, 取值和設值函數則要求與變量名匹配:?MyExcitingFunction(),?MyExcitingMethod(),?my_exciting_member_variable(),?set_my_exciting_member_variable().

說明

一般來說, 函數名的每個單詞首字母大寫 (即 “駝峰變量名” 或 “帕斯卡變量名”), 沒有下劃線. 對于首字母縮寫的單詞, 更傾向于將它們視作一個單詞進行首字母大寫 (例如, 寫作?StartRpc()?而非?StartRPC()).

AddTableEntry() DeleteUrl() OpenFileOrDie()

(同樣的命名規則同時適用于類作用域與命名空間作用域的常量, 因為它們是作為 API 的一部分暴露對外的, 因此應當讓它們看起來像是一個函數, 因為在這時, 它們實際上是一個對象而非函數的這一事實對外不過是一個無關緊要的實現細節.)

取值和設值函數的命名與變量一致. 一般來說它們的名稱與實際的成員變量對應, 但并不強制要求. 例如?int?count()?與?void?set_count(int?count).

總結

以上是生活随笔為你收集整理的GoogleStyle编程代码规范的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。