私は、クラス名、関数名、機能名、変数名、全てにおいて名前をつけるのが苦手です。
変数や関数が増えるたびになんて名前をつけよう、、翻訳サイトで調べて、、、とりあえずこれでつけとこ、という風に命名してしまっています。
会社の方にその様子を見られ一冊の本をおすすめしてくれ、大体目を通せたので要約したり、自分の言葉でまとめたいと思います。
ネーミングの重要性
- 名前の影響について
文書などで関数名や機能名の説明をしている際に、中身の説明を変更した際には問題はありませんが、名前を変更してしまうと他の文書にも影響が出てしまいます。
A機能…A機能とは〜〜〜です。→説明文の修正は、「〜〜〜」を変えればOK。
(別の文書)B機能…この機能はA機能を使用して、×××ます。→前述のA機能の名前を変更すると、（別の文書）に出てくるA機能という名前も変更する必要がある。
つまり、一度命名し、プロジェクトが進んでしまった後に名前と役割が合ってないのでは？とか、あまりいけてないなあ、と思ってしまってもなかなか変更しづらいしそのまま進むしかないような状況に陥ってしまうことがあリます。
- ネーミングによる不具合や、考えのすれ違いを防ぐことができる
あまりいけていない名前がついてしまった場合、後からプロジェクトに入った初見の人は理解がしづらく開発にも影響が出てくる可能性があります。
仕様書を何回も確認する必要があるかもしれないし、コーディングをする際にも機能と役割が合っていないネーミングに合わせて実装することで、何か不具合が起こるかもしれません。
ネーミングチェックをする
では実際にどのようにネーミングセンスを極めるか、という話です。
本には一応「ネーミングに成功するための７つのワーク」として、作業工程を解説していました。
（気になる方は参考文献に載せておくので読んでみてください。）
その中で、誰でもいつでも簡単にできていいなあ、実践してみよう！と思ったものが ループバックチェックです。
「ループバックチェック」は、説明→名前→説明の順序で、くるりと回って元に戻る(ループバック)ように説明が一致すればよし、一致しなければ要注意ということです。
やり方としましては、説明文から名前を考え、今度は逆に名前から推測できる説明文を考えます。
以下に何個か例を記載します。
上記図の説明はWiki先生に書いてあったものを引っ張ってきました。
上記図だと、「お寿司」の説明として「酢飯などと、主に魚介類を組み合わせた和食」はいけている気がしますが、
「酢飯などと、主に魚介類を組み合わせた和食」から「お寿司」を推測するのは難しいのかなあと。（海鮮丼も推測されてしまいそう）
ただ、一致しなかったからといってダメ、というわけではなくあくまで「要注意」とのことです。
もうちょっとエンジニア寄りの話で考えるために、適当にダイエットアプリを作っている想定で機能と説明を考えてみました。
恐らくもっといい名前はあるかと思いますが、とりあえず「名前」と「説明」でぐるぐる回ればOKということで。
最後に
今回、ループバックチェックを食べ物や機能名を例に考えてみましたが、あくまで考え方の話なので、変数や関数やクラス名、モジュール、機能、システム等、全てのネーミングにおいても使える（＋明日からでも実践できる！）技なんじゃないかなと思い、まとめてみました。
参考文献
この記事は以下の情報を参考にして執筆しました。