変数・関数名の命名候補を比較して選ぶ

変数名の命名をAIに尋ねると、通常は名前が1つだけ返ってきます。それらしく見えますが、なぜその名前なのか、他の選択肢は何だったのかが分からないため、チームの規約と合っていなくても気づきにくいです。命名は正解が1つだけの問題ではなく「何を強調するか」を選ぶ問題であるため、比較対象がなければ選ぶこともできません。

形式を表に固定した点がこのプロンプトの肝です。「この名前だけを見て読み取れる処理」の列は、命名者の意図ではなく、初見の人が受ける印象を書かせます。「どのような場合に違和感が生じるか」の列は、現時点では合っていても機能が少し拡張されただけで嘘になってしまう名前をあらかじめ除外します。例えば fetchUser がキャッシュからも取得するようになる瞬間のミスリードなどを防ぎます。

例を1行入れているのは、「方向性が異なる」という指示だけでは曖昧になりやすいためです。例がないまま5つ出させると、getX、getXData、getXInfo のような実質同じ名前が並んでしまいます。方向性の違う3つの例を見せることで、その幅が基準となり、バリエーション豊かな候補が出やすくなります。

制約は2つの事故を防ぎます。命名規則を指定しないとPythonコードに getUserList のようなキャメルケースが混ざり、省略語を禁止しないと短いという理由だけで procMgr のような候補が出てきます。「説明にない機能を名前に含めないでください」は、関数名の推薦において特に重要です。AIが andSendEmail のように実装もしていない処理を名前に付け足してしまうと、後からコードを読む人が誤解してしまいます。

calculateTotalPrice が1つ返ってくるだけです。無難ですが、この関数が品切れ商品を除外していることも、クーポンを適用していることも名前からは分かりません。比較する候補がないためそのまま採用してしまい、数ヶ月後に「合計金額のはずなのになぜ値が合わないんだ」と関数の中身を読み直すことになります。

候補がしっくり来ず再出力させると、直前の候補を少し変えただけのものになりがちです。気に入った方向性を1つ選び、「この方向性だけで5つ」と指定してください。チームのリポジトリでよく使われている名前を5〜6個あわせて貼り付けると、既存の命名ルールに馴染む候補が得られます。