【コード哲学エッセイ】 命名は 「説明」 じゃない。 未来の僕と交わす 「約束」 の話
変数名ひとつに、命を燃やす夜
変数名ひとつが決まらなくて、もう一時間もモニターを睨んでいる。
そんな夜が、あなたにもありませんか?
コーヒーはすっかり冷めてしまい、部屋にはファンの回る音だけが響いています。
`tmp`、`data`、`flag`……。
安易な名前に逃げそうになる自分を、「いや、違う」と押し留める。
「たかが名前じゃないか」
「動けばいいじゃないか」
かつての僕はそう思っていました。
でも、今は知っています。
そのたったひとつの名前が、未来の僕を殺すこともあれば、救うこともあるのだと。
これは、命名を「処理の説明」だと思っていた僕が、数多のバグと裏切りを経て、「命名は約束だ」という哲学にたどり着くまでの話です。
「説明」 しようとするから、 長くなる
駆け出しの頃、僕は「丁寧な命名」=「詳しく説明すること」だと信じていました。
たとえば、ユーザー情報を取得して、データベースに保存しつつ、メールも送る関数があったとします。
当時の僕は、その全てを名前に込めようとしていました。
getUserInfoAndSaveToDBAndSendWelcomeMail()「どうだ、これなら中身を見なくても何をしているか一目瞭然だろう」
と、得意気にさえなっていたのです。
しかし、これは「説明」であって「命名」ではありません。
コードを読むとき、いちいちそんな長いあらすじを読まされる身にもなってください。
しかも、仕様変更でメール送信機能が削除されたら?
名前も変えなければいけません。
もし変え忘れたら、名前は「嘘」をつくことになります。
説明的な名前は、コードの変更に弱く、すぐに腐ってしまうのです。
コードに 「裏切られた」 夜
転機は、ある深夜の障害対応でした。
他人が書いた(あるいは過去の自分が書いた)コードを必死に追っていました。
目についたのは `isValidUser(userId)` という関数。
名前からして、「ユーザーが有効かどうかを `true/false` で返す」関数だと信じますよね?
僕はその戻り値を使って条件分岐を書きました。
しかし、本番環境でそのコードはクラッシュしました。
原因は、その関数の中で「ユーザーが見つからない場合に例外(Error)を投げていた」ことでした。
さらに、データベースへの接続エラーでも例外を投げていました。
「嘘つき……!」
画面の前で、僕は思わず叫びました。
`isValid` という名前は、「真偽値を返す」という暗黙の了解を含んでいるはずです。
それなのに、例外を投げるなんて。
それは、看板に「カフェ」と書いてあるのに、入ったら「牛丼」が出てくるようなものです。
僕はその夜、コードに裏切られました。
そして同時に、僕自身も過去にたくさんの「裏切り」を生み出してきたことに気づき、背筋が凍りました。
命名とは 「約束」 への署名である
その経験から、僕の中で命名に対する考え方が 180 度変わりました。
命名とは、「私はこの関数で、これ以外のことはしません」という契約書への署名なのです。
📌 `get` と名付けたら、データを取ってくるだけ。
計算も加工もしないし、もちろんデータベースを更新したりもしないと「約束」する。
📌 `calc` と名付けたら、計算結果を返すだけ。
外部の API を叩いたりしないと「約束」する。
📌 `create` と名付けたら、新しいリソースを作って返す。
既存のものを使い回したりしないと「約束」する。
この「約束」が守られているコードは、美しい。
なぜなら、中身の実装を一行も読まなくても、安心して使えるからです。
「この関数は `get` だから、何回呼んでも副作用はないはずだ」
「この関数は `is` だから、例外処理はいらないはずだ」
そうやって、未来の自分やチームメイトが、実装の詳細を忘れても(あるいは知らなくても)、名前だけを信じて安全にコードを組み立てられる状態。
これこそが、僕たちが目指すべき「可読性の高いコード」の正体ではないでしょうか。
「迷い」 は未来への誠実さ
もしあなたが今、変数名や関数名に悩んでいるなら。
どうか、その時間を「無駄」だと思わないでください。
「この名前で、未来の僕は誤解しないだろうか?」
「この名前は、中身の振る舞いを正しく『約束』できているだろうか?」
そうやって立ち止まっている時間は、未来の自分、そして一緒に働くチームメイトへの「誠実さ」そのものです。
あなたは今、キーボードを通して、未来の誰かと信頼関係を築いているのです。
命名は「説明」ではありません。
「裏切らない」という、静かなる誓いなのです。
だから僕は今夜も、たったひとつの変数名に悩み、コーヒーを冷まし続けるのでしょう。
それが、エンジニアとしての僕の、誇りなのだから。
あわせて読みたい
▼ 設計という「未来への投資」について考えたいときに
「とにかく速く」を求め続けて燃え尽きそうなときに。
動けばいい、速ければいい、だけでは守れない「未来の自分」のために、
どんな設計を選べばいいのかを一緒に考えるエッセイです。
スピードと安心のバランスを取り戻したい人に。
▼ 過去の迷いや失敗を、ちゃんと「コード」に変えたいときに
最短ルートを探して迷子になっていた二十歳の頃。
その「遠回り」こそが、今の自分を作る重要なソースコードだったと振り返る物語です。
今の迷いや回り道に意味があるのか不安になったとき、自分の歩みをそっと肯定してくれるはずです。
▼ 「できること」だけで、静かに一歩を踏み出したいときに
張り切って大きな目標を立てては、何度も挫折してしまう。
そんな僕がたどり着いたのは、「できること」だけを静かに積み重ねる生き方でした。
焦りではなく、小さな約束から一年を始めたいときに、そっと背中を押してくれる一篇です。
ひとりごと
昔のコードを見返すと、顔から火が出るほど恥ずかしくなることがあります。
でも、その恥ずかしさは「成長の証」でもありますよね。
「命名」は本当に奥が深くて、一生かかっても正解にはたどり着けない気がします。
でもだからこそ、面白い。
この記事が、今どこかで命名に頭を抱えているあなたの、小さな肯定になりますように。

いいなと思ったら応援しよう!
最後まで読んでいただき、ありがとうございます。もしこの記事が「役に立った」「心に響いた」と感じたら、珈琲一杯分サポートいただけると嬉しいです。あなたの温かい応援を力に、また次の創作活動に励みます。