最初に時間をかけて良い名前を考えるべき
変数やメソッド、テーブルやリポジトリの名前をどう決めてますか？
慣れている人なら、後々影響を与えないように慎重に名前を考えると思います。
しかし、名前にまつわるトラブルを経験したことのない初心者の場合、
適当な名前を付けてしまうことが多いようです。
良くない名前は良くない設計を生み、無駄な作業を生みます。
より効率的に開発業務を遂行するためにも、最初に時間をかけて良い名前を考えるべきです。
ここでは、初心者が陥りがちな命名の失敗パターンを挙げてみました。
まずはこれらのパターンに当てはまる名前をつけてないか、ご自身でチェックしてみてください。
タイポ
単語のスペルが間違ってるパターンです。
後から気付くと、非常に恥ずかしいです。
そのうえ直しにくい場所だったりすると、プロジェクトが続く限りずっと人目に触れることになります。
できれば、IDEの設定でスペルチェックをONにし、コミットする前に気付けるようにしてください。
IDE以外での作業であっても、必ずスペルチェックをするようにしましょう。
意味のない言葉を使っている
例えばaやtmpのように、一時しか使わないからと意味のない言葉で変数名を決めてしまうパターンです。
そのときは良くても、後でソースコードを見返したときに、なんの処理をしてるのかわからなくなります。
dataやinfoもよく使いがちですが、これだけだと意味が伝わりにくいので、できればもっと適切な名前をつけてあげるべきです。
和英辞書で見つけた馴染みのない単語を使っている
対応する英単語がわからないため、ネットの和英辞書に日本語名を突っ込んで、
一番上に出てきた単語をそのまま使ってしまうパターンです。
Google翻訳の場合もあります。
その結果、まったく馴染みのない、学術用語のような言葉を選出してしまい、
名前から機能や役割が伝わらないという事態に陥ります。
名前に迷ったら、和英辞書ではなく、codic.jpのようなサイトや、
プログラミングでよく使う英単語のまとめといった記事を参考にしてみましょう。
プロジェクト内で単語が統一されていない
例えば「決済」について、あるところではpaymentと呼び、あるところではbillingと呼んでいる、というパターンです。
双方間違ってはいないのですが、同じ機能であれば同じ単語に統一したほうが、
後々混乱を招かずに済みます。
また、事前に例が存在しない単語を考えなければならない場合、特に名付けには注意が必要です。
なぜなら、以後ずっと、その機能に関してはその名前が使われる可能性があるからです。
命名規約が守られていない
プロジェクトにコーディング規約が定められているなら、それに従ってください。
無ければ、周りのコードを参考にして合わせてください。
それもなければ、採用したフレームワークのルールに従うか、
PHPならPSRのようなグローバルスタンダードな規約に沿って書いてください。
単語の区切りを付けない
なぜか、単語を大文字とかアンダーバーで区切らず、
全ての単語を一繋ぎにして変数名やメソッド名にする人がいます。
単語が少ない方が美しいという意識が働くせいでしょうか。
言うまでもなく単語で区切った方が読みやすいので、命名規約に沿って単語を区切ってください。
ただし、一繋ぎで一単語になるようなプロジェクト内用語があるのであれば、
それは無理に分けない方が良いと思います。
例えば「MAILSENDER」という仕組みがプロジェクトにあり、すでに固有名詞として浸透しているなら、
MAIL_SENDERやMailSenderにするよりも、そのまま使った方が良いと思います。
（固有名詞ではなく、ただメールを送るモジュール、として名前を付けるなら、区切った方が良いです）
IDEだとスペルミスを指摘してくる可能性があるので、単語セットのまま辞書登録しておくと良いです。
やたら長い
命名初心者を脱した人が陥りやすい現象です。
正しい意味を付けるべく名前を考えた結果、
何個も単語が連なった長ったらしい名前ができあがってしまいます。
ここまでに挙げた良くない名前よりも全然マシですが、
もしそのような名前を付けないと意味が伝わらない場面に出くわしたら、
それは設計レベルで見直した方が良いんじゃないかと思います。
ステップアップ
ここで挙げたパターンに陥らなかったら、次はより良い名前はどういうものか考えてみましょう。
命名に正解は無いと思います。私も苦手でいつも時間をかけてます。
色んな方が、色んな考え方を記事にしていますので、
それらに目を通し、常に命名に気を配るように心がけてください。
それだけで、ソースコードはぐっと読みやすくなり、仕事も早くなると思います。
リーダブルコードという本もおすすめです。
あとがき：名前は後から変えにくい
例えばコメントが間違ってるとか、インデントが揃ってないとか、
そういうレベルのミスであれば後から気付いてもすぐ直せます。
また、そもそもロジックが優れていないとか、余計なループが実行されているというのも、
直すのが大変な場合もありますが、これはシステムを改善するために必要な作業なので、
コストはかけやすいです。
しかし、名前の場合はなかなかそうもいきません。
サクッと直してしまいたくても、コメントやインデントのようには直せません。
変数名ならまだしも、テーブル名やリポジトリ名などになると、
ソースコードをgrepだけでは影響範囲が洗い出せない可能性もあります。
さらに、名前がイケてないだけで、システムは問題なく動いています。
問題なく動いているものを修正するのは、それなりに勇気が要るのです。
だからといって名前が間違っている状態を放置していると、
雑草のように根を広げ、修正難易度はどんどん上がっていきます。
名前のミスに気付いたら、早めに修正すべきです。
そして、そうなる前に、最初に名前をちゃんと決めるべきです。