命名:名前を付けることの大切さ

クラス名、メソッド名、変数名。プログラミングにおいては色々なものに名前を付ける。

でも、名前の付け方が悪いと、大変読みづらいコードになる。

今回は、「変数名ってのはこうやって付けるんだよ」とか「クラス名にはこういう定石があってだな…」とかいう話ではなく、そもそも「名前を付ける」ってどういうことなんだろう、というところを再確認したい。

名前を付ける = 他と区別する

あなたが生まれた。あなたにはまだ名前がない。そこであなたのことをこう呼ぶ。「赤ちゃん」。

でも、病院には「赤ちゃん」と呼ばれている他の個体が大勢いる。どれもこれも「赤ちゃん」だ。その言葉だけでは区別できない。

そこで、あなたに名前が付けられる。「太郎くん」。

そうすると、あなたは隣にいる「赤ちゃん」とは違う、「太郎くん」として区別して認識できるようになる。「二郎くん」でも「花子ちゃん」でもない、これが「太郎くん」である、と区別できるようになるのだ。

名前を付けるということには、それが何であるか他と何が違うのか、を示す役割があるのだ。

いくつかのローカル変数が出てくるメソッドにおいて、その変数は何であり、他の変数とどんな役割の違いがあるのか、それが表現された名前を付けないといけない。だから flg1flg2 といった「何を区別しているのか伝わらない変数」はダメだ、と言われるワケだ。

正しく名前が付けられない = 設計ができていない

あるモデル Hoge に関する処理を行う複数のクラスがあった際に、それぞれの名前が上手く付けられず、HogeManagerHogeService などと濁している場合。

中身をよくよく見れば、HogeManager でも HogeService でも値の変換処理が入っていたり、どちらも DB アクセスしちゃっていたり。

こういう場合は、「命名に関するスキル不足」ではなく、「単一責務の原則を守れていない」、つまり設計が正しく行えていない場合だ。

結局のところ、そのクラスは何をするの?」と聞かれた時に、一言で答えられないようであれば、単一責務の原則が守れていない。そのクラスを言い表す適切な単語が出てこなくても仕方がない、といえる。

こういう時は、まず処理の流れを整理し、クラス構成を整える。バリデーションを行うだけのクラス、データをパースするだけのクラス、DB アクセスするだけのクラス、と分けるのである。

そうすれば、各クラスは「結局何をするクラスなの?」という問いに一言で答えられるようになる。そうすればそれをクラス名として与えてやれば良い。すなわち、HogeValidatorHogeFormatterHogeDao のようになるはずだ。

何かを作る時は、責務をベースに分割単位を決め、その責務を表す言葉を名前に付けてやれば良い。こうすると、このコードを読む側は名前から機能や責務・他のクラスとの関係性が推測できるようになるのだ。


命名とは、他と区別を付けること。そのモノの機能や特徴を表現すること。それはすなわちプログラムを設計することであり、デザインすることだ。

適切にデザインされたプログラムは、それぞれの機能や責任範囲が推測しやすく、読みやすくなる。可読性が高まると保守・改修しやすくなり、余計なコストがかからなくなる。

だから名前の付け方はプログラミングにおいてとても重要なことなのだ。