この文書はCode Health: IdentifierNamingPostForWorldWideWebBlogの翻訳です。
長い識別子を調子にのって作るのは簡単だ。長い名前は可読性を改善する。しかし、あまりに 長い名前は可読性を下げてしまう。 GitHubなどを見ると60文字以上の変数名の例は数多く見つかる。 ここで、58文字で俳句を詠んでみよう:
Name variables 名前付け
Using these simple guidelines シンプルガイドで
Beautiful source code きれいなコード (字余り1)
名前は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. これらは除こう。
これらの規則にも例外はある; 君の判断だ。長過ぎる名前は短すぎる名前よりはなおよい。しかしながら、これらの規則に従えば、君のコードは曖昧さもなく、より読みやすいものになる。 読者(未来の君も含めて)はきっとなんて君のコードが明快なんだと感謝するだろう!
-
編集リクエストお待ちしております ↩