C++ のライブラリを読むときに見るところ

C++

そこまで頻繁に読んでるわけではないのですが、たまーに C++ のライブラリを読んだりしています。
そんな時にわたしが特に注意している点を簡単にまとめて見ました。

予約済み識別子を意識してるか

C++ では以下の条件を満たす名前は将来的に予約語になる可能性があるため、回避する必要があります。

  • グローバルスコープを持ち、_ で始まる名前
  • _ で始まり、その次が大文字の名前
  • __ を含む名前

_ から始まる名前は避けたほうがよいという感じです。
例えばよくみかけるのがインクルードガードマクロで、 __XXX_H__ というような名前を使っているのですね。
これは『__ を含む名前』にあてはまるので違反です。
その時点ではコンパイルエラーになるわけではないので結構違反しているコードが多いですね。
あとは違反ではないのですが、メンバ変数で _xxx という風に _ から始まる名前を使っている書き方もちょっと気になったりします。
メンバ変数名であれば問題はないんですが、グローバルスコープだと違反になったりとややこしいので xxx_ という風に末尾に _ をつける事が多いですね。

namespace を使ってるか

基本中の基本。
なのだけれど全く使ってないライブラリが多いのも事実。
C++ を使ってる人なら当然わかるとおもいますが、 namespace を使っていないなんて何が起こるかわかったものじゃないですよね。
以前、namespace を使ってないライブラリの中の人に『std 名前空間と衝突しない設計をしてるので問題がない。コードの短さを優先してる』と言われたことがあります。
それは開発者側の意見で使う側からすれば何が衝突するかわかったものじゃないですよね…。
そもそも短くしたいならユーザ側で using namespace すべきであって開発者側が推奨するべきでは(ry
namespace (と using) は用法用量を守って正しく使いましょう。

クラス名や関数名にライブラリ名の prefix を使っていないか

これもよくありがち。
何故か namespace は使ってないのに関数名やクラス名にライブラリ名を prefix としてつける謎。
namespace を使ってるのに関数名やクラス名にわざわざライブラリ名を prefix としてつけるのはもっと謎。
どんだけそのライブラリ名を書きたいんだ。
ちゃんと namespace を使っていれば prefix は必要はないはずです。
名前の衝突が嫌であれば namespace を使いましょう。

マクロは使っていないか

もちろんマクロを使うべき場面は存在するんですが、C++ では定数定義などをマクロで定義するべきではないですね。
この間見ていたライブラリで static const を使って定数を定義している真下にマクロを使った定数定義があって頭が痛くなりました…。
それ以外にも SAFE_RELEASE() みたいなマクロ関数のも基本的に使うべきではないですねー。
たいていはマクロを使う必要がない場面がほとんどなはずです。

C++11 以降のコードになってるか

むしろライブラリとしては C++03 に準じてた方が使い勝手がいいんじゃないか？と思わなくもないんですが、どのバージョンに対応しているのかはコードの質にも関わってくるので気になりますよねー。
C++14 のコードで書かれてると『お、ちゃんと最新版の C++ に対応していてやるな』とニヤニヤする。

const をちゃんと使ってるか

さすがに使ってないライブラリはほとんど見ませんが、const を使ってるか使ってないかではライブラリの使い勝手が全然違うのでかなり重要なポイントですね。

所感

と、いう感じで簡単にまとめてみました。
そこまで多くのライブラリをみているわけではないのですが、やっぱり予約済み識別子や namespace を意識してないライブラリが結構目立つ印章ですね。
知識として予約済み識別子を知らないのはまぁしょうがないんですが、namespace は使う側にとっても影響してくるのでちゃんと使ってほしいところではありますねぇ。
他の人がどんなところを見ているのかも気になる。

おまけ：逆にあまり見ない点

  • コーディングスタイル
  • インデント
  • コメントの有無

全く見ないといえば嘘になるんですが、コーディングスタイルとかはよっぽど奇抜ではない限りそこまで気にしませんね。
インデントもタブだろうがスペースだろうがライブラリに置いてはあまり重要なポイントではないです。
コメントもまぁあったらあったでいいんですが、ドキュメントがちゃんと書かれていればまぁ使う上では問題ないかなーと思うので気にならないですね（自分で保守する必要があるライブラリであればまた違ってきますが…。