慣例として、hoge.hにはクラスの宣言を書き、 hoge.cppにはその実装、というか、 メソッド、じゃなかった、メンバー函数の中身を書きますね。 どっちもhoge.cppに書いてもいい場合もなくはありませんが、 ほとんどの場合は無条件に分けて書いておいた方が、 のちのちトラブルに巻き込まれずに済みます。
でもね、これが実際にはわずらわしいんですよ。
例えばメンバー函数の宣言は、函数名と引数並び、戻り値の型を、 hoge.hとhoge.cppに2回書かなくちゃなりません。 ということは当然、修正するときもいちいち両方直さなければなりません。
じゃあ単純にコピーすればいいかっていうと、そうではないんですね。 仮想函数かどうか、とか、引数省略時の値は、hoge.hだけに書くことになっています。
この点については、JAVAは面倒がなくていいですね。
プログラムの開発中は、gunya.cppの編集中にちょっとhoge.cppを参照する、 なんてことが頻繁に起こります。 見ているとhoge.cppの方に変なことがあるのに気がついて、 修正をはじめたら結構時間がかかって、いつの間にかgynya.cppの方で 何をするつもりだったか忘れたりすることも。
いや、これが本題ではない...
hoge.cppを参照していて、更にhoge.hを調べたくなることが起こります。 この函数はpublicだったっけ、とか、この引数は省略できるんっだったけ、とか、 いう具合です。 でもこれが結構わずらわしい。ファイルをエディターで開いて、該当箇所を 検索するのに、最低でも10秒位はかかるんじゃないでしょうか(計ったことないけど)。
そこで工夫は、
hoge.cppだけ見れば必要なことはわかるようにする
ということです。 つまり、hoge.hにしか書かないような情報も、重複して書いておくのです。
という訳で、hoge.cppの函数の頭書きをこんな風にするのはいかが?
/*=============================================================
*/
long
Hoge::Munyamunya(
int are,
int kore, /* = 0 */
char dore) /* = ' ' */
{
....
}
ポイントその1。函数の先頭をみつけやすくするため、 水平線を引きます。 ポイントその2。水平線を見れば、 函数がpublicかprotectedかprivateかがわかるようにします。 私はこんな風に使い分けています。
| public | ===================================== |
| protected | ------------------------------------- |
| private | ..................................... |
上の欄ほど、つまり、より公開されているものほど、黒っぽい線になっているのが 味噌です。ちなみに、別の機会に説明しますが、もっと上位の ******************************という線も使うことがあります。
ポイントその3。static函数はその旨先頭近くに書いておきます。 この函数を使う側から見ると、staticかそうでないかの区別は重要です。 ちなみに、virtualかそうでないかは改めて書かないことにします。 構築子なんかは別として、virtualにする方を原則にしているためで、 逆にvirtualにしない理由がある場合にその旨書くようにします。 なお、「函数はすべからくvirtualにすべし」というスローガンについては また別の機会に。
ポイントその4。引数は1行に1つずつ書きます。 ポイントその5。引数の省略値を書いておきます。
これくらい書いておくと、開発中にhoge.hを参照したくなる回数は ぐっと減ります。 gunya.cppの中でhogeのprivate函数を呼んでしまった、なんていう 間違いを事前に防げる訳です。 まあ、この函数をpublicに設計変更することもある訳で、 こんなときは水平線も引き直さなければなりません。
問題点はhoge.hと記述が一致しなくても気がつきにくいこと。 とはいうものの、この不一致のために変なバグが入り込んだりした 経験は今のところありません(直すときはちゃんと両方直すんです)。
理想をいえば、hoge.cppに合わせてhoge.hを書き換える ツールを作って、Makefileの規則に追加すること。 これいいね。 自分の流儀の頭書きにさえ対応できればいいのなら、 それほど手間をかけなくて済みそう。