新人プログラマーに読ませて
欲しいネーミングの大切さ

ネーミングについてまじめに長文を書いてみました。もし、あなたの会社にネーミングに疎い新人プログラマーがいたら読ませてやってください。

ちなみに、この記事はシステム開発のネーミングについて書いています。また、このブログの特性上、英語でのネーミングを想定していますが、日本語のネーミングでも同様に考えることができると思います。

1. ネーミングの大切さ

一般に、熟練のプログラマーほど、プログラミングにおける ネーミングに時間をかけます。それはなぜでしょうか。

あなたが付けたその変数名 data は、その時点では、自分のために付けた「目印的なもの」であったかもしれません。しかし、そのソースコードを引き継いだ担当者など多くの人が、その名前を見ることになります。

// データを取得する
var data = getData(1);

そしてその名前は、そのソースコードを見る人に「僕は○○する変数だよー!」と訴えかけます。 あなたが適切な名前を付けていれば、読む人はすぐに意味を理解し、さっさと自分の仕事を片付けることができます。反対に、あなたにしか解らない暗号になってしまっていたら、読む人は誤った認識をしてしまうかもしれません。もしかしたら、勘違いした後の担当者が、誤った修正を加えて謂れのないバグを踏んでいるかもしれません。

 

このように、ネーミングはあなただけの為のものではなく、そのソースコードを見る人への配慮でもあるのです。あなたは、自分のネーミングがプロジェクトの生産性や品質に影響するということを考えなければなりません。

 

経験を積んだ熟練者は、こういったネーミングがプロダクトやプロジェクトメンバーに与える影響を経験から知っています。だから、プログラミングにおける ネーミングに時間をかけるのです。

 

ネーミングは、それを人間がそれを見て理解できるようにするためのユーザーインターフェースを考える作業とも言い換えることができます。これは、英語に限らず日本語でデータベースのテーブル名などを命名する時も同じです。ネーミングは、より良い(文字ベースの)コミュニケーションを生むためのスキルです。そしてそれは、プログラム言語と並ぶ基本的なスキルとして扱われるべきなのです。

2. プログラムに意味を持たせる

良いネーミングはバグを発見する手がかりにもなります。以下のコードには、簡単なバグがあります。わかるでしょうか?

if (file.notExists()) {
    file.delete();
}

文章にしてみると「if file (dose) not exit. File delete. / ファイルがなかったらファイルを削除する」となり、文章的におかしいということがわかりますよね。

 

うまく構成されたネーミング構造は、コンパイラーが発見できないようなセマンティックなエラー(意味的な矛盾)を人間に気付かせてくれます。 これがネーミングの力です。変数 a, b, c で構成されたプログラムでは、発見することは難しいですよね。

 

私たちが、アセンブラではなく高級言語でプログラミングをしている理由を考えてみてください。適切にネーミングをすることは、プログラムに人間が理解できる意味を持たせるという事でもあるのです。

3. 意図を伝えるネーミング

ネーミングは、自分だけの為のものではありません。そのコードを見るすべての人の為のものでもあります。だからあなたは、それを見る人へ「あなたの意図」を適切に伝えるように努力しなければなりません。

考えてみてください。あなたは、なぜそのクラスを作ったのでしょうか。なぜ、その変数を作ったのでしょうか。必ず意図があったはずです。

var d = 0;  // ???

もし、それが読む人に伝わらなければ、あなたのソースコードを後で変更する人は、あなたが作った変数やクラスを変更することなく、プログラムを修正しようとするでしょう(触らぬ神に祟りなし的にね)。そのようなコミュニケーション不足は、カオスと化したソースコードを生み出す原因にもなります。

 

だからあなたは、その変数・クラスを作った意図をソースコードに残さなければなりません。健全なソースコードは、より良いコミュニケーションから生まれます。そして、それはオリジナルのコードを書くあなたから始まらなければなりません。

4. 良いコードと良いネーミングは仲良し

良いコードと良いネーミングは、とても仲良しです。その理由は簡単です。今作ろうとしているもの(例えばメソッド)が、何をする物なのかが、頭の中できちんとイメージ(つまり設計)できていれば、自然に名前は出てくるはずです。反対に、何を作るかまとまっていないのに、良い名前が付けられるはずはないですよね?。良く設計されたコードほど、良い名前を付けやすいのです。

 

共通化の名目で、なし崩し的に重複した処理を共通化するような時に、たいていネーミングに困るのは、こんな理由です。そんな時は、いくら英語辞書の前で悩んでもいい名前はでてきません。もう一度コード設計を見直してみるべきです。

 

もちろん、良いコードとは良いネーミンングだけから生まれるものではありません。コーディングテクニック・コメント・クラス設計など多くの技術によって成り立ちます。ここで大切なのは、それらが独立したスキルではなく、強い関係性を持っているという事です。

良いコードを書きたいなら良いネーミングを学び、良いネーミングをしたいなら良いコード設計を学ばなければならないということを覚えておいてください。

 

ちなみに、意図を伝えるという意味では、コメントとネーミングは似たところがあります。しかし、この両者には、1つ大きな違いがあります。それは、コメントは考えがまとまっていなくても書けてしまう点です(言い訳をずらずらとね w)。

5. 単語の選択がすべてではない

初心者のネーミングにありがちなことは、ネーミングの良し悪しが、単語の選択によってのみ決まると思い込んでいる事です。

 

それに対し、上級者のネーミングは、ネーミングしようとしているそれの前後関係/構造を捉え、その一連の意味的関係の中で識別できる名前を決定しようとします。

前後関係は、プログラムに限らずあらゆるところに存在します。例えば、クラスとメソッド・変数と変数・メソッド名・はたまたテーブル間のリレーションシップなど、あらゆるものが関係性や構造を持ち、名前を持ちます。

 

実際、個々のネーミングによって表現できる情報は限られています。しかし、構造や関係性の中でネーミングを捕らえ、文章のように協調・関係させながら表現することで、個々のネーミングでは表現できなかった、意図を表現できるようになります。

6. 最後に

ネーミングに背を向けることは簡単です。変数名 a, b, c … でもプログラムは動いてくれます。でも、それではあなたのスキルは、ある一線を越えることはありません。コーティングとは表現する・そして伝えるという事でもあるということを、覚えておいてください。そしてあなたは、自身の表現を、磨いていかなければなりません。

 

今すぐできることは、今まで何気なく付けていた名前に疑問を持つことです。英語だけではありません。日本語だって案外難しいものです。

 

精神論的な記事になってしまったので少し反省しています。もう少し具体的に踏み込んだ記事も書きたいと思いますので、たまにチェックしてくださいね。


Kenji in codic

codic のリードプログラマー / デザイナーです。時間があれば、英語やネーミング、NLPについて研究したりしています。