この文書はCode Health: IdentifierNamingPostForWorldWideWebBlogの翻訳です。

長い識別子を調子にのって作るのは簡単だ。長い名前は可読性を改善する。しかし、あまりに 長い名前は可読性を下げてしまう。 GitHubなどを見ると60文字以上の変数名の例は数多く見つかる。 ここで、58文字で俳句を詠んでみよう:

Name variables　　　　　　　　　名前付け
Using these simple guidelines　　　シンプルガイドで
Beautiful source code　　　　　　　きれいなコード　（字余り¹）

名前は2つのことを守らなくてはならない：明瞭さ（それが何を表すのか）と正確さ（それが何を表さないのか）。 ここで判断の助けとなる、いくつかのガイドラインを示す：

変数の型宣言から明らかな単語を除外

// 悪い、型によってそれが何なのか分かる:
String nameString;
List<datetime> holidayDateList;

// よい:
String name;
List<datetime> holiday;

重要でない詳細を除外

// 悪い、過度に具体的な名前は読みにくい:
Monster finalBattleMostDangerousBossMonster;
Payments nonTypicalMonthlyPayments;

// よい、区別しなくてはならない他のモンスターや支払いがないなら:
Monster boss;
Payments payments;

周辺の文脈から明らかな単語を除外

// 悪い、文脈の繰り返し:
class AnnualHolidaySale {
  int annualSaleRebate;
  boolean promoteHolidaySale() {...}
}

// よい:
class AnnualHolidaySale {
  int rebate;
  boolean promote() {...}
}

どんな識別子にも適用できる語を除外

思い当たりはあるだろう: data, state, amount, number, value, manager, engine, object, entity, instance, helper, util, broker, metadata, process, handle, context. これらは除こう。

これらの規則にも例外はある; 君の判断だ。長過ぎる名前は短すぎる名前よりはなおよい。しかしながら、これらの規則に従えば、君のコードは曖昧さもなく、より読みやすいものになる。 読者（未来の君も含めて）はきっとなんて君のコードが明快なんだと感謝するだろう！

編集リクエストお待ちしております ↩