More Related Content
Similar to 可読性について リーダブルコード part1(表面上の改善)
Similar to 可読性について リーダブルコード part1(表面上の改善) (20)
可読性について リーダブルコード part1(表面上の改善)
- 8. - 命名
- 明確で正確な単語を選ぶ
- getSize() => getHeight()
- get/fetch/download 状況によって適切で明確なものを選ぶ
- 汎用的な名前は避ける
- retval => sumSquares
- ただし、情報の一時的な保管で生存期間が短いケースでは汎用的な名前が役に立
つこともある(ループイテレータなど)
- 抽象的な名前よりも具体的な名前を使う(例:値の単位など)
- delay => delayMs
- 重要な属性を追加する
- password => plaintextPassword
- comment => unescapedComment
- 全てに属性を追加するのではなく、「バグ」の元になりそうな所へ追加する
適切な名前(命名)
- 9. 適切な名前(誤解されない名前)
- 誤解されない名前
- filter = 濾過する
- filterは条件にあったものを「選択(select)」なのか「除外(exclude)」なのか不明確
- 限界値はmin/maxを使う
- 未満(限界値を含まない)なのか以下(限界値を含む)なのか
- booleanはis/has/can/shouldを使う
- trueとfalseの意味を明確にするため
- 11. コメント1
- コメントの目的
- 書き手の意図を読み手に知らせる
- コードを書いている本人は、頭の中に大切な情報があるが、読み手はその情報が失われてし
まう
- コメントすべきで「ない」こと
- 価値のないコメントは記入しない
- 価値のないコメントとは
- コードからすぐにわかることはコメントに書かない
- getHeight() // 高さの取得
- コード以外の「新しい情報」を提供しているか
- 背景や経緯
- コメントのためのコメントはしない
- コードがおかしい可能性、ひどいコードにはコメントではなく名前を変えるべき
- コード自体が読みやすいことが大前提
- 12. コメント2
- 自分の考えを記録する
- 優れたコメントとは「考えを記録する」ためのものである
- コードは絶えず進化しているので、その過程での欠陥を文章化すべき
- TODOやFIXMEなどのアノテーションを活用(影響範囲が大きい時など)
- 基本その場で改善できるところは改善する(ボーイスカウトの原則)
- 定数には背景となるコメントを残す
- 定数の定義は、その定数が何をするのか、なぜその値を持っているのかという「背景」
が存在する場合が多い
- 読み手の立場になって考える
- 質問されそうなことを想像する
- 関数の内部にロジック分けしたブロック毎へ「要約」したコメントをする
- コメントは正確で簡潔に
- 「これ」「それ」絶対NG
- 短く単純で直感的な言い回し