プログラムの命名規則

プログラムなんて動けばいいじゃないかと思われるかもしれませんが、命名規則というのは開発の効率とメンテナンスの事を考えると確実に守った方が良いルールになります。

開発効率

命名規則が無い場合、それぞれの開発者が好き勝手に名前をつけるため、例えば５人開発者がいると、各々が別名で同じものを呼ぶ事があります。

その場合他の開発者が書いたコードは他人から見て読み難い名前がつけられているコードになるので、可読性が低くなります。

ひとつの例

例えば誰でも一緒になりそうな「魚」であったとしても開発者の数が多くなればなるほど一致させることは難しくなります。

例えばプロジェクトの途中で他の方が書いた部分を修正しなくてはいけなくなった場合、名前のルールが違うといちいち調べなくてはわからず開発効率がどんどん下がっていきます。

メンテナンス

プログラムは作ったら終わりではありません。

組み込み製品のように１０年〜２０年スパンで更新されないものもありますが、基本的には問題があったら直していこうという考え方が多いように思います。

というのもソフトウェアは人間が作っている以上、バグがあるのは仕方がない事です。

例えば世界トップクラスのエンジニアが関わっているGoogle,Amazon,Microsoft等のソフトウェアでもバグをゼロにする事には残念ながら今の所成功していません。

自分のような世界トップとは程遠い普通ぐらいのデベロッパーがアプリを作ったら確実にバグが組み込まれてしまうのは間違いありません。

さらに言うと一度作ったプロダクトをずっと使うことが出来るのは一部の限られた環境のみです。

組み込み製品では、テストをどれだけきっちりやったところで周りの環境、デバイスが変わってバグが顕在化するかもしれません。

Webの仕組みであってもビジネス環境の変化に合わせてソフトウェアも修正を行う必要があります。例えば１０年前のレジを今使うというのはハードウェア的にはまだ使えてもソフトウェアとしては無理があります。

ではメンテナンスすることになった際に名前や関数名がバラバラだったらどうでしょうか？

単純に解りにくいですよね？

なので命名規則は自分だけでなく、後から開発するメンバーにとっても利益となるものです。

当然逆もしかりなので、何かのソフトウェアを後からメンテナンスする際に読みやすいコードはとても助かります。

日本と北米の違い

実は日本と英語圏での命名規則の違いはそれほど多くはありません。

もちろん日本ではコードのコメントを日本語にする場合もあります。しかし、コメント部分を除くと利用している言語は同じものを利用しているため基本は同じ形式になります。

それよりも、会社や組織による違いの方が大きいように思います。

日本では英語はあくまでも第二言語であるため、若干違和感のある名前になってしまっている場合も否めませんがそれは気がついたタイミングで修正したら良い話なので、ミスを恐れずに作って行けば良いように思います。

会社や組織によって大きく異る

いくら同じプログラミング言語、さらにはオープンソースのコードを利用しいてもメンバーが異なれば異なる命名規則になる場合も多々あります。

極端な話、命名規則は関わっているエンジニアが全員わかりやすく理解できるものであればなんでもかまいません。

しかし、新規プロジェクトメンバーが参加した際に混乱を招くようなものは除外するべきです。

しかしこ確実にコレが正解だと言えない場合も多く、開発者の多くは関数名やクラス名を考えることに時間を消費していることも多々あります。

崩れたコード

命名規則は基本的に開発の早い段階から取り入れ遵守するか、定期的にレビューを行い開発者に対して命名規則を思い出してもらう必要があります。

プログラマーならわかると思いますが、一度崩れてしまったコードをメンテナンスしなくてはいけなくなったらどう思いますか？

特定の人物だけにしか修正できなくなってしまったコードを誰にでもメンテできるコードに戻すことはほぼ不可能です。

英単語 vs ローマ字

これだけは確実に英単語をおすすめします。

というのも、ローマ字は日本語をアルファベットに当てはめただけで、当然日本人にしか理解することはできません。

もしローマ字を採用するのであればひらがなや漢字の方が日本人にとって読みやすいハズです。実際に使うかどうかは別の問題ですが、一部の言語では日本語を関数や変数等に利用することも可能です。

なので外国人には読めず、日本人にも読みにくいというメリットが感じられないローマ字の利用は可能な限り避けるべきです。

しかし、日本語話者のみしか将来的にもメンテナンスする事が無いとわかっている場合はローマ字が採用されるかもしれません。これは組織判断によるものです。

勝手に新しく作らない

同じような機能がいくつもあるシステムを見ることもよくあります。

どうしてこうなってしまったのか？と見ていくと根本に命名規則が違ったため、開発者が見つけることが出来ず新規開発してしまったという場合もありました。

これは命名規則と少し逸れますが、開発時にはできるだけ同じコードを利用すべきです。

具体的な規則は？

ここからは具体的にどのような規則が良いか例を挙げていきます。

関数名の長さは

関数名の長さに制限がある場合を除いて、無理に短くする必要はありません。

世界的に利用されているlinuxのコードを少し見てみます。

linux/aegis128-neon.c at master · torvalds/linux

Linux kernel source tree. Contribute to torvalds/linux development by creating an account on GitHub.

GitHubtorvalds

例えばこのコードの関数宣言部分では以下の通りになっています。

決して短い関数名ではないものの、他の関数名とも矛盾せず、何をしているのか理解しやすい名前設定となっています。

void crypto_aegis128_init_neon(void *state, const void *key, const void *iv);
void crypto_aegis128_update_neon(void *state, const void *msg);
void crypto_aegis128_encrypt_chunk_neon(void *state, void *dst, const void *src,
					unsigned int size);
void crypto_aegis128_decrypt_chunk_neon(void *state, void *dst, const void *src,
					unsigned int size);
int crypto_aegis128_final_neon(void *state, void *tag_xor,
			       unsigned int assoclen,
			       unsigned int cryptlen,
			       unsigned int authsize);

しかし長過ぎる関数名は可読性を著しく低下させるので、２行にまたがってしまうような長さは避けるべきです。

void calculate_area_of_roomba_cleanup_at_least_three_times();

しかしこれほどに関数名が長くなってしまうということは、ひとつの関数に機能を詰め込み過ぎている状態になっているように思います。

命名規則も大切ですが、全体として適切な粒度が揃っていることも重要な要素の一つです。

長い単語は短縮するか？

とても長い単語は短縮する場合もありますが、現代のプログラミング言語では文字数制限により短くする必要性や、短くした事によるメリットがほぼ無いためそのままにしておきます。

どちらかというと短く短縮してしまった事により意味がわからなくなってしまうケースや、最悪の場合意図とは逆に読まれてしまうデメリットの方が大きくなります。

Of や In を使う？

しかし、ほとんどの変数名や関数名に入ってしまうような場合は名前の付け方がくどいように思うのでもう少しシンプルにするべきです。

// ちょっとくどいかなーと思うレベル
bool create_record_of_users_in_pririty_list();

// OK
bool create_record_for_pririty_user();

命名規則の宗派

命名規則にも大きな分類として、どのように単語を区切るのかという宗派があります。

これはプロジェクト全体で統一されるべき規則ですが、現実的には利用しているライブラリやAPI単位で異なる場合もあります。

同じ人が開発しているのに混ざっていると、何故だ・・という疑問が沸いてきます。

ここからは auto speed up という関数名を例に見ていきます。

キャメルケース

autoSpeedUp

先頭を除く各単語の頭文字を大文字にしたもの。自分が経験したプロジェクトではこれが一番主流。

これはラクダの背中のようにボコボコしていることから来ているようです。

スネークケース

auto_speed_up

各単語を_(アンダースコア)でつないで表記する。物理的に単語が離れるため可読性という意味ではキャメルケースより良い場合も多いが、単語数が多くなるほど名前が長くなる。

ケバブケース

auto-speed-up

スネークケースの_(アンダースコア)に変わり、ハイフンで各単語をつないでいる。

ちなみにケバブとはこのようにお肉をレイヤーにして焼いた料理で中央に串が刺さっている。誰も知りたか無いと思うがもりしーの大好物である。

英語的な正しさと理解しやすさ

例えばライトのON/OFFをする関数名があるとしましょう。

この場合どちらが理解しやすいでしょうか？

(A)対象であるlightを前に

bool light_turn_on();
bool light_turn_off();

(B)動作であるturn_on/offを前に

bool turn_on_light();
bool turn_off_light();

この場合、英語としてそれっぽいのは(B)でしょう。

また、プログラムで扱う対象がライトだけであれば(A)でも(B)でもそれほど大差は無いように思います。

しかし、ライトの他にエアコンやファンがあったら、と考えると(A)である方がプログラムとしてメンテナンスしやすいものになるように思います。

対象となるモノを先頭に持ってきた場合

// light
bool light_turn_on();
bool light_turn_off();

// fan
bool fan_turn_on();
bool fan_turn_off();

動作を先頭に持ってきた場合

// light
bool turn_on_light();
bool turn_off_light();

// fan
bool turn_on_fan();
bool turn_off_fan();

個人的には対象となるモノを先頭に持ってくる方が好きですが、動作が先というルールが採用されていれば、それはそれでかまいません。

命名規則は、どちらが正解と言えないケースも多々あります。

まとめ

謝辞

この記事はご質問頂いた内容にインスパイアされ作成しています。ご質問ありがとうございました。

もりしの質問箱です

質問・回答はこちら

Peing -質問箱-