Aikido

記述的な変数名を使用して自己文書化コードを書くべき理由

読みやすさ

ルール
使用 説明的 変数 名を使用してください。
非常に 短い 変数 名前 変数 コードを 不明瞭になる。

サポート言語: 45+

はじめに

単一文字または暗号のような変数名は、読者に文脈から意味を推測させるため、コードを一目で理解できなくなります。 d 日付、期間、距離、またはデータを表す可能性があり、関数全体を通じてその目的を追跡するには精神的な努力を要する。説明的な名前(例: ユーザー作成日時 または リクエスト期間 意図を認知的負荷なしに即座に明確にする。

なぜそれが重要なのか

コードの保守性:不明瞭な変数名は理解を遅らせる。開発者は実際のロジックに集中する代わりに、x、tmp、valが何を表すのかを解明する時間を使う。 不適切な命名では、新規ロジックの配置場所や既存値間の関連性が不明確になるため、コードの拡張性も低下する。さらに、曖昧な名前はコードベースの検索性を損なう。tmpやvalを検索しても意味のある結果が得られないためだ。この問題は、数か月後にコードを再確認する際や新規メンバーが加わった際に深刻化する。

バグの紹介: 曖昧な名前は誤った変数を使用する可能性を高める。複数の変数が類似した難解な名前を持つ場合(d1, d2, d3開発者は間違ったものを使用する可能性があり、名前が意味的な手がかりを提供しないため、コードレビューを通過する微妙なバグを引き起こす。

コード例

非準拠:

function calcAmt(u, qty) {
    const p = u.prc;
    const d = u.disc || 0;
    const t = p * qty;
    const a = t - (t * d);
    const tx = a * 0.08;
    return a + tx;
}

なぜ不正確なのか: 変数名のような u, p, d, tそして、それらはその目的について何も明らかにしない。読者は計算の論理を追跡して理解しなければならない。 p 価格は、 d 割引です。 t 小計であり、 a 税抜き金額です。

✅ 準拠:

function calculateOrderAmount(product, quantity) {
    const price = product.price;
    const discount = product.discount || 0;
    const subtotal = price * quantity;
    const amountAfterDiscount = subtotal - (subtotal * discount);
    const tax = amountAfterDiscount * 0.08;
    return amountAfterDiscount + tax;
}

なぜこれが重要なのか: 各変数名は、その変数が何を格納しているかを記述しています。 割引後の金額 計算状態を明確に示す 税金 は明確であり、 製品 そして 数量 関数の本体を読み取ることなく、その引数を明らかにする。

結論

文脈を必要とせず意図が伝わる名前を使用してください。簡潔さよりも明確さを優先してください。 合計金額tp 実行には何のコストもかからないが、理解においては大幅な時間を節約する。

よくある質問

ご質問は?

単一文字の変数名は許容されることがあるか?

はい、限定された文脈では可能です。ループカウンター(i, j, k)は慣例的で明確です。関数型プログラミングにおけるラムダ関数のパラメータ(x => x * 2)は、操作が明らかな場合に問題ありません。数学的操作では慣用的な名称(座標のx, yなど)を使用できます。ただし、これらは小さなスコープ(数行程度)に限定すべきです。

変数名はどのくらいの長さにするべきですか?

明確であるのに十分な長さで、実用的なのに十分な短さ。userDataはuよりも優れ、dataAboutTheCurrentUserBeingProcessedよりも優れている。2~4語を目安とする。それ以上必要なら、その変数は独自の型やクラスに値する概念を表している可能性がある。

btn、msg、ctx などの略語はどうですか?

あなたの分野で一般的な略語は問題ありません。JavaScriptではctx(コンテキスト)、req(リクエスト)、res(レスポンス)は広く理解されています。ただし、新規メンバーには明らかでないプロジェクト固有の略語は避けてください。迷ったら、正式名称を明記しましょう。

古いコードをリファクタリングする際に変数名を変更すべきですか?

はい、ただし戦略的に。他の理由で関数に手を加える場合、変更の一環として変数名の改善も行うこと。名前が実際に混乱やバグを引き起こしている場合を除き、名前の変更のみを目的としたプルリクエストを作成しないこと。すべての参照が正しく更新されるよう、IDEのリファクタリングツールを活用すること。

言語キーワードとの衝突をどのように処理すればよいですか?

具体性を追加:class の代わりに userClass、type の代わりに itemType。または文脈を活用:userCategory、productKind。数字を付加しない(class1、class2 など)— 意味が失われる。制約により、より具体的な名称が必要であることが判明する場合が多い。

今すぐ安全を確保しましょう

コード、クラウド、ランタイムを1つの中央システムでセキュアに。
脆弱性を迅速に発見し、自動的に修正。

クレジットカードは不要。