関数名に数字を使うことの是非

Prompt

メソッド名をつける時、
どんな理由であれ名前に数字を含めるのは好ましくない？
例えば、parseOr0() div0Safety() みたいな…
(書いてて気付いたけど、結構読みづらいね、この名前)

---

なるほどね！メソッド名に数字を含めるのはどうかっていう話だね。parseOr0()とかdiv0Safety()って例を出すあたり、君も「ん？これどうなんだ？」って感じてるのが伝わってくるよ！INFPの君が、コードの「表現」や「意味」について深く考えている証拠だね。

---

メソッド名に数字を含めるのは好ましくない？ 🤔

結論から言うと、君が例に挙げたようなケースでは、「好ましくない」 という意見が多数派だよ！ そして、君自身が「読みづらい」と感じたその感覚が、まさにその理由なんだ。

なぜ好ましくないのか？

1. 可読性の低下:

   • parseOr0(): 「パース・オア・ゼロ」って読むかな？それとも「パース・オー・ゼロ」？ 0が数字のゼロなのか、アルファベットのオーなのか、ぱっと見で分かりにくいことがある。

   • div0Safety(): 「ディブ・ゼロ・セーフティ」？ 分割（division）とゼロが混ざって、一瞬「？」ってなる。

   • プログラミングは、書く時間より読む時間の方が圧倒的に長いから、ぱっと見て意味が伝わらない名前は避けるべきなんだ。

2. 意味の不明瞭さ・曖昧さ:

   • 数字は、それ自体が具体的な意味を持つことが多いけど、メソッド名の一部になると、その数字が「何を表しているのか」が曖昧になりがちだよ。

   • parseOr0()だと、「パースできなかったら0を返す」って意味合いだろうけど、parseOrDefault()の方が「デフォルト値を返すんだな」って一目でわかるよね。

   • div0Safety()だと、「0で割るのを安全にする」って意図だろうけど、handleDivisionByZero()やensureNonZeroDivisor()の方が、何をするメソッドなのかが明確になる。

3. 検索性の低下:

   • コードエディタで検索するときに、0なのかOなのか、あるいは数字をローマ字で表現しているのか、などが混在していると、目的のメソッドを見つけにくくなることがあるよ。

4. プログラミング言語の慣習:

   • 多くのプログラミング言語のコミュニティで、メソッド名や変数名には、単語やフレーズを使って意図を表現する慣習が根付いているんだ。数字を多用すると、その慣習から外れて浮いてしまうことがある。

じゃあ、全く数字を使っちゃダメなの？

もちろん、全くダメというわけではないよ！ 特定の状況では、数字を含めるのが自然で、かつ可読性を損なわない場合もあるんだ。

数字を使っても良い例:

• バージョン番号や特定の回数を表す場合:

  • v2Calculate()（バージョン2の計算）

  • retry3Times()（3回リトライ）

  • getDataPage1()（1ページ目のデータを取得）

  • このように、数字が明確な意味を持つ、固有の識別子として機能する場合は問題ないことが多いよ。

• 数学的な計算やアルゴリズムに関わる場合:

  • calc3DSum()（3次元の合計を計算）

  • sha256Hash()（SHA-256ハッシュを計算）

  • findPrimeNumbersUpTo100()

  • この場合も、数字が計算の文脈で明確な意味を持つから、可読性を損ねにくいんだ。

---

君の例を「より良い」名前にするなら？

君が挙げた例は、まさに「意味が曖昧になりがち」な典型例だね。

• parseOr0()

  • 改善案: parseIntOrDefault(input, 0) のように、引数でデフォルト値を渡すか、メソッド名に**Default** や Fallback を含めて、parseOrDefault()、tryParse() (成功したら値、失敗したらnull/Optional) のようにすると、より意図が明確になるよ。Javaのセクションで話したヘルパーメソッドの考え方が役立つね！

• div0Safety()

  • 改善案: 「何を安全にするのか」「どう安全にするのか」を明確にする。

    • ensureNonZeroDivisor(): ゼロ除算を防ぐことを保証する。

    • handleDivisionByZero(): ゼロ除算を処理する。

    • divideWithZeroCheck(): ゼロ除算チェック付きで除算する。

    • または、JavaのOptionalのように、計算結果が存在するかもしれないし、しないかもしれないことを示すOptional<Double> safeDivide(double numerator, double denominator)のような設計も考えられるね。

---

まとめ

• メソッド名に数字を含めることは、それが読みづらく、意味を曖昧にする可能性が高い場合は、避けるのが好ましい。

• 特に、「～だったら0」「～を安全にする」のような、機能の一部を数字で表現しようとする場合は、より具体的な英単語（Default, Fallback, Check, Handle, Ensureなど）を使うと、格段に分かりやすくなるよ。

• 数字が、バージョン、回数、数学的な定数、明確な識別子として機能する場合は、含めても問題ない。

INFPの君が、自己表現を通じて心のバランスを整えるように、コードもまた、意図が明確で、他の人に伝わる美しい表現を目指すのは、素晴らしいことだよ！ メソッド名一つとっても、そのコードの哲学が表れるんだ。

これからも、疑問に思ったことはどんどん深掘りしていこうね！