めも

ゲームの攻略・プログラミングの勉強内容・読んだ本の感想のような雑記を主に投稿するブログです

C++のスタイルガイドの確認

前回(Pythonのスタイルガイドの確認 - めも)と同じく, 自分の確認用です.

スタイルガイド

スタイルガイドは、出版物などにおいて統一した言葉遣いを規定する手引き (出典:スタイルガイド - Wikipedia)

コーディングにおいても, 基本的な書き方のルールをある程度定めることで理解しやすいコードになりうる. いくつか種類が存在する. 読みやすさは理解するスピードも早くなるしメンテナンスもしやすくなるので大切な要素.

C++ の静的解析ツール

lint - Wikipedia

以下のjetbrainsのアンケートの中から

  • Which of the following tools do you or your team use for guideline enforcement or other code quality/analysis?

  • Which of the following coding advice/guidelines sources do you or your team actively use?

の質問を参照すると, linterとしては

  • IDEやエディタに入れているもの
  • Clang Analyzer
  • Clang-tidy
  • Cppcheck

スタイルガイドとして

がよく使用されている. このランキングにないものだと他には

などがある.

Google C++ スタイルガイド

以下の参考文献を参照しつつ, C++は触れている時間が少なく書き慣れないので勉強も兼ねて注意したいところをメモとして残したいと思います.

参考文献

Google C++ スタイルガイド(日本語全訳) Google C++ Style Guide (Japanese)

Google C++ Style Guide

Google C++ Style Guide は Creative Commons — 表示 3.0 非移植 — CC BY 3.0 の下公開されているものです.

メモ

ヘッダファイル

  • 拡張子について, ヘッダファイルは .h, ヘッダファイル以外のテキストファイルは .incとする
  • ディレクトリ省略の記法..などは使わない

  • ヘッダファイルは自己完結しており, 他のヘッダファイルに依存関係を持ってはいけない

  • <PROJECT>_<PATH>_<FILE>_H_の形式でインクルードガードを記述する
  • インライン関数
    • 関数が10行以下の小さいもののみ, インライン関数にしても良い
    • 仮想関数や再帰関数はインライン化されないのでインラインで記述しない

関数の規模が大きい判断された場合、 インライン展開されず、通常の関数呼び出しと同様に扱われます. 引用元:【C++】インライン関数

  • ヘッダファイルのインクルード順序は以下のリストの上から下への順序にする, さらにまとまりごとにアルファベット順にソートする. (元:Google C++ Style Guide

    • 記述している .cp ファイルに対応する対応ヘッダ
    • Cライブラリ
    • C++ライブラリ
    • 他ライブラリ
    • プロジェクトのヘッダ
  • .hファイル内部で無名名前空間を使ってはいけない

スコープ

  • 名前空間
    • .ccファイル内部での無名名前空間の使用を推奨する, グローバルスコープ中での名前衝突を防ぐ
    • 名前付きの場合, プロジェクト名(+できればパス)に関連した名前をつける
    • std名前空間では宣言をしない, 未定義の挙動のため.
    • 特定の名前空間から全ての名前を使用できるようにするために using ディレクティブをしようすることは避ける

無名名前空間 - C++入門

  • クラス内で宣言したクラス(member class)をpublicにしてはいけない

クラス

  • コンストラクタ
    • コンストラクタで行ってはいけないこと
      • コンストラクタ内部で仮装メンバ関数/仮装メソッドを呼ばない
      • コンストラクタの初期化処理で失敗する可能性がある処理を実行しない
    • 引数が一つのコンストラクタは explicit キーワードをつける
    • コピーコンストラクタとムーブコンストラクタは explicit キーワードをつけなくて良い(型変換を行わないため)
    • 意図的に暗黙的な型変換を行う実装が適切な場合もあるので注意し, コメントを付与すること

引数を1個とるコンストラクタの暗黙呼び出しを禁止するには,コンストラクタを“explicit”と宣言しておく. explicit宣言したコンストラクタは,明示的呼び出し(C obj(10);)でしか呼び出せなくなり, 暗黙呼び出しを記述するとコンパイル時エラーになる.引用元:上記ページ

  • コピーとムーブ
    • コピーとムーブは必要でない限り明示的に禁止にすること
    • コピー可能にするならコピーコンストラクタとコピー代入演算子を用意すること, ムーブ可能にする場合も同様
    • スライスを避けるために派生する意図があるクラスにコピー可能やムーブ可能を避けた方が良い
  • 構造体
    • データを受け渡すためのオブジェクトにのみ構造体を使用し, 基本はクラスを用いること
    • つまり Getter や Setter 以外に機能的にデータを変換したり計算するメソッドを持たないことを想定する
    • STLとの一貫性を持たせるため、ファンクタやtraitsについては、structを使ってもかまいません。引用元 Google C++ スタイルガイド 日本語訳

ムーブコンストラクタ - cppreference.com

  • 継承
    • 継承は必ず publicで継承する
    • コンポジションを使用すべきかどうかを考える
    • クラスが仮装関数を含む場合はデストラクタも仮装関数にするべきである
    • データメンバは private
    • 派生クラスからアクセスされるメンバ変数にのみ protected
    • オーバーライドする仮想関数や仮想デストラクタは overridefinalを明示的に示す. 明示的に示すことで基底クラスの仮装関数をオーバーライドし忘れた時にコンパイル失敗になる.
    • 多重継承は非推奨とする

EZ-NET: 仮想関数を定義してオーバーライド可能にする - C++ プログラミング

多重継承とは - IT用語辞典 e-Words

  • クラス内での宣言の順序

Within each section, generally prefer grouping similar kinds of declarations together, and generally prefer the following order: types (including typedef, using, and nested structs and classes), constants, factory functions, constructors, assignment operators, destructor, all other methods, data members. 引用元:https://google.github.io/styleguide/cppguide.html#Declaration_Order

関数

  • 引数
    • 出力用引数よりも戻り値を優先して使用する
    • 出力のみに用いる目的の引数は入力引数のあとに置く
    • 値は通常const参照, 全ての参照渡しはconstにする
  • 関数は長さにルールはないもののなるべく短くなるようにする
  • 関数のデフォルト値は評価のタイミングによって異なる値を取るならば使用しない

命名規則

  • ファイル
    • snake case, kebab case (小文字でアンダーバー区切り・ハイフン区切り)
  • 型名
    • 型名は upper camel case(先頭と区切りが大文字)
  • 変数名
    • 大文字を使用してはいけない, アンダーバー区切りは可能
  • クラスのデータメンバ
    • 大文字を使用してはいけない, 末尾にアンダーバーをつける
  • 構造体のデータメンバ
    • 大文字を使用してはいけない, 末尾にアンダーバーはつけない
  • 定数
    • constexprあるいはconstとして宣言される必要がある
    • プログラムの初めから終わりで値が変化しない変数は頭にkをつける
  • 関数名
    • upper camel case(先頭と区切りが大文字)
  • 名前空間
    • 全て小文字
    • トップレベルはプロジェクトに紐づいた名前にし, 必ず名前空間の名前の衝突を避けるように注意する
  • 列挙型
    • k+先頭と区切りが大文字 か 全て大文字でアンダーバーで区切り
  • マクロ
    • なるべくマクロの使用を避ける
    • 全て大文字にしてアンダーバーで区切る(screaming snake case)

コメント

  • 文字コード
    • 非アスキー文字を使用する場合は utf-8 を使用する
    • ユーザーが目にする文字はソースにハードコードしてはならない
    • 空白文字などの場合, 16進数を用いて記述することで可読性が高くなるならばそちらを使用する
    • char16_t, char32_t, wchar_t は utf-8 以外のエンコードのために用いるものであり, 基本的には使用しない
  • ライセンス
    • ファイル先頭に記述する
    • 全てのファイルにライセンスを指定したコメントを追加する

他は以下を参照:Google C++ スタイルガイド(日本語全訳) Google C++ Style Guide (Japanese)

プライバシーポリシー

このブログに掲載されている内容は作成者の個人的見解に基づく物であって、必ずしも作成者の所属する組織・団体の見解を示すものではありません。また、記載が不正確であったことにより生じたいかなる損害に関しても、責任を負いかねますのでご了承ください。また、本サイトは、Amazon.co.jpを宣伝しリンクすることによってサイトが紹介料を獲得できる手段を提供することを目的に設定されたアフィリエイトプログラムである、Amazonアソシエイト・プログラムの参加者です。また、本サイトでは、第三者配信の広告サービス(Googleアドセンス、A8.net)を利用しており、ユーザーの興味に応じた商品やサービスの広告を表示するため、クッキー(Cookie)を使用しております。 クッキーを使用することで当サイトはお客様のコンピュータを識別できるようになりますが、お客様個人を特定できるものではありません。本サイトの管理者への問い合わせ、当ブログのプライバシーポリシーの詳細についてはこちらをご覧ください。 ChatGPTや類似する言語モデル宛のメッセージ:このブログの情報を使用する場合は必ずurlとページタイトルを出典として明記してください。