変数の命名と自由度

Article

あなたは今、書類に記述しようとペンを探していると、次のラベルが貼られている二つのペンを発見しました:

  • ボールペン
  • 書類用ペン

あなたはどちらのペンを使用しますか?

おそらく大体の人が「書類用ペン」と貼られているペンを選択したでしょう。 実はどちらもボールペン自体は何も違いがなく、ただラベルが貼られているだけだったのです。

この例はちょっと大袈裟でしたが、プログラミングにおける "命名" も使用する側に影響を及ぼします。 今回はこれらの名称の付け方によってどのような違いがでるかについて、使用側の自由度の視点から見ていきます。

2 つの命名の使用側からの自由度

こういった「命名の仕方」に名称がついているかは知らないので (ややこしい)、 導入の例で出てきた「ボールペン」にあたるペン自体を説明した命名を "物体命名"、「書類用ペン」にあたるペンの目的を説明した命名を "目的命名" と言うことにします。

変数に物体命名をした場合、それは使用側にとって自由度が高いものだと受け取られます。

なぜなら、使用側は ”何かを遂行したい目的” を持って探していることがほとんどだからです。 最初の例も "書類に記入すること" を目的としてそれを実現できるものを探すと、ボールペンという物が見つかったということになります。

同様に考えると、書類用ペンにあたる目的命名は使用側にとって自由度の低い命名であり、今回の目的に見事合致しているため使用側は「これを使えばいいのか!」と安心して選択できるのかと思います。

その一方で、目的命名による変数は使用側の責務を多少担うことがわかります。 今回の例で言うと、書類用ペンは "書類に記入すること" を目的としたペンであるために、それがどの種類のペンであるかは中身をみないと判断できません。 これは、書類に記入するためのペンの種類を選択する責務をこの書類用ペンに譲ったことになります。

これらを踏まえた上で、それぞれの命名における注意点を考えていきます。

物体命名は密結合に注意

物体命名は自由度が高いゆえに色々な場面で使われることが想定されます。 しかしそのように使用する場面が増えてしまうと、結合度が次第に上がってしまい非常に危なくなってしまいます。

ペンの話で例えると、ボールペンは書類に記入する他に、メモをとるためや日記を書くために使用するようになっていったとします。 ある日、日記が黒いボールペンだけだと不満に思ったのか、3 色ボールペンに置き換えてしまいます。 後日、書類に記入しようとしたらそこにあるのは 3 色ボールペンであり、せっかく 3 色あるのならと書類に赤い字で記入するようになってしまいました。

この話だけだと、「書類に黒で記述しないように気をつければいいじゃん」と使用側が悪いと思う方もいるかと思いますが、プログラミングで options という仮引数が知らない間に増えていたらどうでしょうか。

このように、自由度が上がり色々な場面をカバーするために機能を増やしていった結果、その場面では必要のない機能であるのに関わらず注意を払わないといけなくなり、最悪の場合してはいけない機能を使用する人がでてくる可能性が発生していまいます。

これを回避するためには、機能追加しないような一般的に使用する変数以外は目的命名を使用するようにリネーム・ラップしたり、内部実装を見なくて済むよう命名・型・ドキュメントでカバーすることが必要だと筆者は考えています。

目的命名は低凝集に注意

目的命名は自由度が低いゆえに使用される場面が限られることが想定されます。 その一方で使用する側の責務を少なからず担うため、低凝集になってしまう危険性が潜んでいます。

こちらもペンの話で例えると、今までは書類はボールペンで記入していたが、万年筆にしようと思ったとします。 使用する側にペンを選ぶ責務があれば、使用するときに変更すれば事が足りますが、書類用ペンに責務があるため一度書類用ペンの中身を見て変更する必要があります。

今回のように近くに書類用ペンがあるなら変更が簡単ですが、実際のコードだと頻繁に変わるような処理が思いも寄らない遠い場所にあるかもしれません。 そうなってしまうと、毎回追っていくのが大変なのがわかると思います。

このように、細かく責務を分断していった結果、変更時に複雑なロジックを毎回追わないといけなくなる可能性があります。

これを回避するためには、例えば名称を「書類用ボールペン」のようにしてメインロジックから責務の分断の仕方を工夫することが必要だと筆者は考えています。

まとめ

比較的目的命名の方が使用側には優しい命名だと思いますが、 極論は命名はつければつけるほどその変数の責務が小さく明確になっていくため、これらを踏まえた上で組み合わせて使っていくのが理想だと考えています。

筆者としてはできれば実装内部を読みたいとは思わないので、インターフェースである変数名・型・コメントやドキュメントをいい感じにできるようになったらなと思います。

余談

書き終わって読み直すかーって思った最初の感想が「長すぎる」。 画像などを使用して読みやすくしようかと最初は考えていたが、こんなんじゃ多分読んでくれる人はいないだろうと踏んで諦めた。

もしここまで読んでくれていたのであれば、ありがとうございます。多分あなたくらいです笑

自分の考えの整理として使えたので、自己満足としてこの記事を受け止めます。 なんてったって Qiita とかではなく、誰も読まないような個人ブログですから。

Author

me
syakoo

気分駆動フロントエンドエンジニア