見出し画像

【コード哲学エッセイ】 命名は 「説明」 じゃない。 未来の僕と交わす 「約束」 の話

変数名ひとつに、命を燃やす夜

変数名ひとつが決まらなくて、もう一時間もモニターを睨んでいる。
そんな夜が、あなたにもありませんか?

コーヒーはすっかり冷めてしまい、部屋にはファンの回る音だけが響いています。
`tmp`、`data`、`flag`……。
安易な名前に逃げそうになる自分を、「いや、違う」と押し留める。

「たかが名前じゃないか」
「動けばいいじゃないか」

かつての僕はそう思っていました。
でも、今は知っています。
そのたったひとつの名前が、未来の僕を殺すこともあれば、救うこともあるのだと。

これは、命名を「処理の説明」だと思っていた僕が、数多のバグと裏切りを経て、「命名は約束だ」という哲学にたどり着くまでの話です。

「説明」 しようとするから、 長くなる

駆け出しの頃、僕は「丁寧な命名」=「詳しく説明すること」だと信じていました。

たとえば、ユーザー情報を取得して、データベースに保存しつつ、メールも送る関数があったとします。
当時の僕は、その全てを名前に込めようとしていました。

getUserInfoAndSaveToDBAndSendWelcomeMail()

「どうだ、これなら中身を見なくても何をしているか一目瞭然だろう」
と、得意気にさえなっていたのです。

しかし、これは「説明」であって「命名」ではありません。
コードを読むとき、いちいちそんな長いあらすじを読まされる身にもなってください。
しかも、仕様変更でメール送信機能が削除されたら?
名前も変えなければいけません。
もし変え忘れたら、名前は「嘘」をつくことになります。

説明的な名前は、コードの変更に弱く、すぐに腐ってしまうのです。

コードに 「裏切られた」 夜

転機は、ある深夜の障害対応でした。
他人が書いた(あるいは過去の自分が書いた)コードを必死に追っていました。

目についたのは `isValidUser(userId)` という関数。
名前からして、「ユーザーが有効かどうかを `true/false` で返す」関数だと信じますよね?

僕はその戻り値を使って条件分岐を書きました。
しかし、本番環境でそのコードはクラッシュしました。

原因は、その関数の中で「ユーザーが見つからない場合に例外(Error)を投げていた」ことでした。
さらに、データベースへの接続エラーでも例外を投げていました。

「嘘つき……!」

画面の前で、僕は思わず叫びました。
`isValid` という名前は、「真偽値を返す」という暗黙の了解を含んでいるはずです。
それなのに、例外を投げるなんて。
それは、看板に「カフェ」と書いてあるのに、入ったら「牛丼」が出てくるようなものです。

僕はその夜、コードに裏切られました。
そして同時に、僕自身も過去にたくさんの「裏切り」を生み出してきたことに気づき、背筋が凍りました。

命名とは 「約束」 への署名である

その経験から、僕の中で命名に対する考え方が 180 度変わりました。

命名とは、「私はこの関数で、これ以外のことはしません」という契約書への署名なのです。

📌 `get` と名付けたら、データを取ってくるだけ。
  計算も加工もしないし、もちろんデータベースを更新したりもしないと「約束」する。

📌 `calc` と名付けたら、計算結果を返すだけ。
  外部の API を叩いたりしないと「約束」する。

📌 `create` と名付けたら、新しいリソースを作って返す。
  既存のものを使い回したりしないと「約束」する。

この「約束」が守られているコードは、美しい。
なぜなら、中身の実装を一行も読まなくても、安心して使えるからです。

「この関数は `get` だから、何回呼んでも副作用はないはずだ」
「この関数は `is` だから、例外処理はいらないはずだ」

そうやって、未来の自分やチームメイトが、実装の詳細を忘れても(あるいは知らなくても)、名前だけを信じて安全にコードを組み立てられる状態
これこそが、僕たちが目指すべき「可読性の高いコード」の正体ではないでしょうか。

「迷い」 は未来への誠実さ

もしあなたが今、変数名や関数名に悩んでいるなら。
どうか、その時間を「無駄」だと思わないでください。

「この名前で、未来の僕は誤解しないだろうか?」
「この名前は、中身の振る舞いを正しく『約束』できているだろうか?」

そうやって立ち止まっている時間は、未来の自分、そして一緒に働くチームメイトへの「誠実さ」そのものです。
あなたは今、キーボードを通して、未来の誰かと信頼関係を築いているのです。

命名は「説明」ではありません。
「裏切らない」という、静かなる誓いなのです。

だから僕は今夜も、たったひとつの変数名に悩み、コーヒーを冷まし続けるのでしょう。
それが、エンジニアとしての僕の、誇りなのだから。

あわせて読みたい

▼ 設計という「未来への投資」について考えたいときに

「とにかく速く」を求め続けて燃え尽きそうなときに。

動けばいい、速ければいい、だけでは守れない「未来の自分」のために、
どんな設計を選べばいいのかを一緒に考えるエッセイです。

スピードと安心のバランスを取り戻したい人に。

▼ 過去の迷いや失敗を、ちゃんと「コード」に変えたいときに

最短ルートを探して迷子になっていた二十歳の頃。

その「遠回り」こそが、今の自分を作る重要なソースコードだったと振り返る物語です。

今の迷いや回り道に意味があるのか不安になったとき、自分の歩みをそっと肯定してくれるはずです。

▼ 「できること」だけで、静かに一歩を踏み出したいときに

張り切って大きな目標を立てては、何度も挫折してしまう。

そんな僕がたどり着いたのは、「できること」だけを静かに積み重ねる生き方でした。

焦りではなく、小さな約束から一年を始めたいときに、そっと背中を押してくれる一篇です。

ひとりごと

昔のコードを見返すと、顔から火が出るほど恥ずかしくなることがあります。
でも、その恥ずかしさは「成長の証」でもありますよね。

「命名」は本当に奥が深くて、一生かかっても正解にはたどり着けない気がします。
でもだからこそ、面白い。

この記事が、今どこかで命名に頭を抱えているあなたの、小さな肯定になりますように。

2026© おおとろ

いいなと思ったら応援しよう!

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