マジックナンバー — 意味不明なリテラルが散らばる

コードの中に、説明もなく 86400 や 7 や 0.08 が直接書かれている。書いた本人には自明でも、読む人には「この数字は何？」という謎かけになります。これがマジックナンバーです。

横にスクロール

症状：どう気づくか

• 条件式や計算の中に、由来の分からない数値がそのまま書かれている。
• 同じ値が複数の場所に登場する（* 1.08 があちこちに）。
• レビューで「この数字なに？」という質問が繰り返し出る。

if user.age >= 18 and cart_total * 1.08 > 10000:
    apply_discount(cart_total * 0.05)

18（成人年齢？）、1.08（税率？）、10000（送料無料の閾値？）、0.05（割引率？）——どれも意図が説明されていません。

なぜ悪いのか

第一に、読み手を止める。数値の意味を、周辺のコードや仕様書から推測せねばならない。1.08 が消費税なのか、何かの係数なのかは、その数字だけからは決して分かりません。コードは書く回数より読まれる回数のほうがずっと多いので、この摩擦は積み重なります。

第二に、変更漏れを生む。税率が変わったとき、1.08 がコード中の何箇所にあるか、そのすべてが本当に税率なのか（1.08 はたまたま別の意味かもしれない）を、一つずつ確認して直す羽目になります。1箇所でも漏れれば、そこだけ古い税率で計算し続けるバグになります。

直し方

名前付き定数に抽出する。 値ではなく、意味に名前を付けます。

ADULT_AGE = 18
TAX_RATE = 1.08
FREE_SHIPPING_THRESHOLD = 10000
MEMBER_DISCOUNT = 0.05

if user.age >= ADULT_AGE and cart_total * TAX_RATE > FREE_SHIPPING_THRESHOLD:
    apply_discount(cart_total * MEMBER_DISCOUNT)

こうすると、コードが意図を語り始めます。TAX_RATE は1箇所で定義され、税率改定はそこを直すだけ。名前が付いたことで「これは税率だ」という前提もはっきりします。

まとめ

• マジックナンバーは、意味の説明なく直書きされたリテラル。由来不明の数値・文字列が散らばる状態。
• 害は読み手を止めることと、変更漏れを生むこと（同じ値が複数箇所に散る）。
• 直し方は名前付き定数への抽出。値でなく意味に名前を付け、1箇所で定義して使い回す。
• ただし 0/1 や自明な値まで定数化しない。文字列（マジックストリング）は enum でまとめると誤字も防げる。