個人的ゲームプログラミング備忘録
haruki目次
ヘッダーの書き方について
サンプルコード（少し長いので畳んでいます）
/**
* @file ファイル名.h
* @brief 簡単な説明
* @author 作成者名
* @date 作成日(年/月/日)
* @details 詳細な説明
*/
#ifndef HOGE_H
#define HOGE_H
#include "インクルードしたいファイル名"
class Hoge
{
public:
// 関数
public:
// 定数
private:
// 関数
private:
// 変数
};
#endif // HOGE_H
情報の記載
ヘッダーの書き方の1番目の説明
なぜ
ファイルがどのような役割をしているのかが書かれているだけで「くみとる」の時間を短縮できる。
また、その後の可読性も上がります。
ヘッダーに限る事ではありませんが、可読性は重要です。
私の考え
ファイルの先頭
/**
* @file ファイル名.h
* @brief 簡単な説明
* @author 作成者名
* @date 作成日(年/月/日)
*/
・↑上記の内容を最低限書いています。
・これも多いと思うのであれば@fileと@briefだけでも良いと思います。
・説明不足なら@details(詳細な説明)を書く事もあります。
ただ、ファイル名や簡単な説明だけでも理解できるのがベストだと思います。
見る所は少ない方が助かりますからね。
関数の場合
/**
* @brief 簡単な説明（～する関数）
* @param[in] a(引数名) 引数の説明
* @param[out] b(引数名) 引数の説明
* @return bool 戻り値の説明
* @details 詳細な説明
*/
・@briefを最低限書いています。
・引数があるなら@paramを追加で書きます。 inとoutの違いはこちら
・@returnはあまり書きません。理由は、関数の説明や関数自体から理解できると考えているからです。
・説明不足なら@detailsを書く事もあります。
変数の場合
// 説明
↑上記の内容を書いています。
これ以上に書く事がないと思っています。
参考リンク
haruki再定義の防止
ヘッダーの書き方の2番目の説明
なぜ
C++ では、特に何も配慮していないと、同じヘッダーファイルを 2 回インクルードしたときに、
定義が重複しているとしてエラーになるからです。
私の考え
/**
* @file ファイル名.h
// 省略
*/
#ifndef HOGE_H
#define HOGE_H
// #pragma once
// 処理
#endif // HOGE_H
↑上記の内容を書いています。
・#pragma onceはヘッダーが再インクルードされなくなります。しかし、コンパイラに依存します。
・なので、#defineを使います。これはコンパイラに関係なく防止してくれます。詳細は*こちらを
ちなみに
全て大文字にしているのは、視認性を上げるためです。こちらとか考えています。
#endifの後にコメントを書いているのは「何の」か分かりやすくするためです。無くても問題はありません。
参考リンク
harukiクラス内の書き方
ヘッダーの書き方の3番目の説明
なぜ
他者の可読性を上げるためです。
サンプルコード(長いので畳んでいます)
class Hoge
{
// 関数
public:
/**
* @brief コンストラクタ
*/
Hoge();
/**
* @brief デストラクタ
*/
~Hoge();
/**
* @brief 死んでいるか
*/
IsDead();
// 定数
public:
// 初期体力
static const int INIT_HP;
// 関数
private:
/**
* @brief ダメージを与える
*/
Damage();
// 定数
private:
// 最大体力
static const int MAX_HP;
// 変数
private:
// 体力
int hp;
};
名前は適当です。
私は昔まで変数が先でprivate:が先にありました。理由はヘッダーで変数をすぐに確認したかったからです。しかし、他者が見る場合はprivate:は見られるべきではなく、public:な要素を見る必要があると考えてサンプルコードの形にしています。
ちなみに
関数の中でコンストラクタやデストラクタは見られる必要はなく、先にゲッタやセッタの様なアクセサの方が上だとも思っています。
しかし、コードの順番が崩れるので可読性が下がると考えて、サンプルコードの形にしています。