1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Google C++ Style Guideを読む4~コメント・フォーマット~

Last updated at Posted at 2025-12-24

初めに

Google C++ Style Guide
ライセンスCC-By 3.0 License


ttsukiさんの日本語訳
ライセンスCC-By 3.0 License


初回の記事

2回目の記事

前回の記事


Inclusive Language

命名やコメントを含むすべてのコードに対して、他のプログラマーが不快に感じられる可能性のある語を使用しない("master" and "slave", "blacklist" and "whitlist")。

また、特定の人に言及する場合には中性的な言葉を使用する。

人の場合は(単数であっても)"they","them","their"

その他のものに対しては"it","its"(これらは人に対して用いない)

Comments

コメントはコードの可読性を保つために必要不可である。
ただし、コメントよりも明確な命名のほうが遥かに優れている。

Comment Style

コメントは、一貫性が保たれている場合、///* */どちらを使用しても良い(//)が一般的

## File Comments

各ファイルはライセンスに関する定形分で始める。

また、そのファイルに含めるべき内容を記述するべきである。

Legal Notice and Author Line

すべてファイルに、プロジェクトが最小しているライセンスに関する定型文を含める。

ファイルに大きな変更を加えた場合、そのファイルの作者の行を変更する。
新規作成のファイルには著作権や筆者の行を含めない。

Struct and Class Comments

構造体やクラスの宣言には、目的、使い方を示すコメントを記述する。

Function Comments

関数宣言時には、その関数の使い方について説明する。
定義時には、関数で行われる操作について説明する。

Variable Comments

変数の名前で説明すべき。

Class Data Members

メンバ変数の目的は明確でなければいけない。
明確に表現できない詳細をコメントとして記述する。

Global Variables

グローバルである必要性について記述する。

Implementation Comments

トリッキーな部分にはコメントを記述する。

Explanatory Comments

トリッキーなコードブロックには事前に説明を記述する。

Function Argument Comments

複数の呼び出しで同じ値を使用する場合、定数として引数にする。
bool型はenumに置き換える。
設定オプションを持つ場合にはそれらを保持する構造体を定義する。

引数の説明をコメントに書くことは最終手段。

Don'ts

明白なことを記述しない。

Punctuation, Spelling and Grammar

コメントは文法、スペルに気をつける。
明瞭性や可読性は大切。

TODO Comments

一時的、暫定コードや、完璧ではないコード等に対してはTODOコメントを記述する。

初めにTODOを書き、続けてバグ管理番号や対応者を記述する。

Formatting

emacsの設定ファイルが用意されている。

Line Length

各行は最大80文字。
ただし、可読性やその他の適切な理由がある場合にはこの限りでない(#include、インクルードガード、using宣言)。

Non-ASCII Characters

基本的には使用しない。
使う場合はUTF-8フォーマットを使用する。

u8接頭辞の使用は避ける。

Spaces vs. Tabs

スペースを使用。インデントはスペース2つ。

Function Declarations and Definitions

関数戻り値の型は関数名と同じ行に記述する。

ReturnType ClassName::FunctionName(Type par_name1, Type par_name2) {
  DoSomething();
  ...
}

1行に収まらない場合

ReturnType LongClassName::ReallyReallyReallyLongFunctionName(
    Type par_name1,  // スペース4個でインデント
    Type par_name2,
    Type par_name3) {
  DoSomething();  // スペース2個でインデント
  ...
}

Lambda Expressions

ラムダ式の引数と関数本体は、通常の関数と同様にフォーマットする。
参照キャプチャについて、アンパサンドと変数名の間にはスペースを入れない。

短いラムダ式はその場で記述することもできる。

Floating-point Literals

浮動小数点リテラルでは、常に小数点を書き、両側に1桁以上記述する。

Function Calls

関数呼び出しは、全体を1行でかくか、引数リストを改行して(スペース4つでインデント)記述する。

Braced Initializer List Format

波括弧での初期化は、関数呼び出しと同じようにフォーマットする。

Looping and branching statements

(){の間にはスペースを1つ入れる。
if...else文には必ず{}で加工。
()内の;後にはスペースを入れる。

- for (int a = f();a == 10) {}  
+ for (int i = 0; i < 10; ++i)

Pointer and Reference Expressions and Types

ドット演算子やアロー演算子周りにはスペースを記述しない。

+ x = r.y;
+ x = r->y;

ポインタ型や参照を用いるとき、*&の前にスペースを置かない。

+ char* cl
+ std::vector<char*>

Boolean Expressions

ブール式が行の長さを超える場合、行の区切りについて一貫性を保たせる。

Return Values

return 文を不要な()絵囲わない。

Variable and Array Initialization

=(){}いずれを使用しても良い。

整数型の初期化に{}を用いると、小さい型への変換を防ぐことができる。

+ int pi(3.14);  // pi == 3
+ int pi{3.14};  // Error

Preprocessor Directives

#は常に行頭に置く。
インデントも行わない。

Class Format

publicprotectedpricateの順で並べる。
これらはスペース1文字でインデントする。

クラスの宣言の順序に従う。

Constructor Initializer List

コンストラクタの初期化子リスとは、全て同じ行煮含めるか、スペース4つでインデントする。

Namespace Formatting

名前空間ではインデントしない。

Horizontal Whitespace

水平方向の空白は場所によって使い分ける。
行末に空白を置かない。

General

行末コメントにはスペース2つ。

{の前にはスペース。

継承や初期化子リストの:の前後にはスペースを置く。

Loops and Conditionals

ifforなどのキーワードは直後二スペースを入れる。
範囲forの:の前後にスペースを置く。
case:にはスペースを置かない。

Operator

代入演算子の前後にはスペースを置く。
二項演算子の前後にも同様。
()の内側にはスペースを置かない。

Templates and Casts

<>の間にはスペースを置かない。

std::vector<std::string> x;

Vertical Whitespace

縦方向の空白は控えめに。
インデントによって明確に区切られている場合には空行を追加しない。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?