リーダブルコード読書メモ　～その２～　

こちらの続きです。

hatek47320.hatenablog.com

3章

  • 誤解を生むような名前ではないか常に意識する
    • filter→select,exlude（filterではちょっとあいまいすぎるので、選択する、除外する、などより明確にする）
    • limit→max,min（最大値か最小値かを明確にする）
    • 範囲を指定するときはfirst、last
    • ～～の間、を示すときはbegin、end
    • boolについて
      • 「これからtrue or false」か「すでにtrue or false」かがわかるようにする。need_password、user_is_authenticated
      • 接頭辞にis、has、can、shouldが一般的に付けられる
      • Rubyの場合は接尾辞に「?」が言語仕様として付けられるはずなのでいらないかも
    • getの罠
      • getは便利な言葉で使いたくなるが、より明確な単語を選ぶ（特にJavaとかだとgetterでgetを利用したりするので若干混同するかも）
    • sizeは単にサイズを返すものから、サイズを算出するものもあるのでそれは明確にする。後者はcountとかつけるといいかも
  • まとめ
    • いい名前は誤解されない名前である。第三者がその名前を見て読む人によって解釈が変わらないことが望ましい
    • いくつか名前を考えて、色々な角度で検討する。人と相談するなどが必要

4章

  • 見た目が美しいコードを目指す

    • レイアウトの話。余白、段落の長さ、配置、順序など。
    • コードは文章なので、レイアウトの観点で読みやすいに越したことはない。
    • 改行位置は他のものにそろえ、見やすくする
    • 似たようなコメントがクラス内に散見されるのはよくないので、その場合は共通化して上部に書くなど工夫する
    • 縦のラインは（インデント？といっていいのかな）そろえる
    • 変数の並び順は意味のある並びとする
      • アルファベット順、呼び出される順、など

  • まとめ

    • コードも文章なのでレイアウト的な読みやすさが大切
    • コードスタイルは個人の好みでわかれるが、同じコード内にばらばらのスタイルがあるのはわかりにくい。統一すること

5章

  • コメントについて
    • コメントは書き手の意図を読み手に伝えることである。
      • いたずらにコメントを入れるべきでない。コメントすべきでないものもある。
    • コードの処理を逐一コメントにするのはよくない
      • ～～の処理をする、～～の値を返す、～～の定義をする、などはコードを見ればわかる
      • 仮にコードそのものがわかりにくい場合はリファクタリングする。コメントを入れることで改善してはいけない
    • 何をコメントすべきか
      • 自分の考えや改善点を入れる
        • 一般的には～～と書くべきだが、～～の理由により～～というコードにした、という特殊な場合の補足
        • TODOコメントによるコード改善の提案
        • 定数やパラメータの設定値の理由
      • 全体像が分かるようなコメント
      • このファイル内のコードは何をしているか、が分かるような要約コメントがあるといい
  • まとめ
    • コメントはいたずらに入れるべきではない。優れたコード＞ひどいコード＋優れたコメントである
    • コードを読んでわからないような情報を入れる

終わりに

3～5章についてザーッと読んでいきましたが、レイアウトや名前のチョイスなど、通常の文章の書き方にもあると感じました。ソースコードも文章も、他人に見やすく、わかりやすいように気を付けたいですねえ