【技術本】リーダブルコード

https://amzn.to/4nLLzi5


【技術本】リーダブルコード

へポスト
コードを複数メンバーで共有し理解しやすく管理して生産性を上げるための珠玉の指針が書かれた著作。
表面的な見た目の問題から、内部のロジックを改善するリファクタリングまで、実装の具体例を踏まえて紹介してくれるので非常にわかりやすい。
なにも、コードを他人と共有するためだけでなく、数ヶ月後の自分の実装内容のコードを忘れかけた自分にも役に立つ事ばかり書かれているので、コードを書く人は必須の登竜門的著作だと言える。
コードを書く初心者から中級以上の熟練者まで、幅広い層に響く著作だと感じた。

------
●１章：理解しやすいコード

コードは人がりかいしやすいものでなくてはならない
コードは他の人が最短で理解できるように書かなければならない
＞コードを使っているのは自分だけ、誰が得するの？
　＞コードに見覚えない６ヶ月後の自分かも知れない

●第一部：表面上の改善

●２章：名前に情報を詰め込む
・明確な単語を選ぶ
GetPage..どこから？インターネットからならFetchPage, DownloadPageのほうが明確
・汎用的な名前を避ける
tmp, retvalなどの汎用的名前は避ける
tmpは生存期間が短くて、一時的な保管が最も大切な変数だけに使うべき
ループ用のカウント変数：i,j,k...なども目的にあったわかりやすい名前にする
・抽象的より具体的な名前
ServerCanStart > CanListenPort
--run_locally > --extra_logging
・接尾辞や接頭辞を使って情報追加
ミリ秒をあらわすなら、_msを末尾に追加
・名前の長さを決める
スコープが小さければ短い名前でもいい
　省略形はNG BackEndManager >> BEManager
・名前のフォーマットで情報を伝える
Googleのコード:
変数 lower_separated : 小文字をアンダースコアで区切る
　クラスメンバ変数 offset_ :末尾にアンダースコア。通常変数と区別
　定数 kConsntanName : マクロ特別するため
JQUery:
ライブラリ関数($だけの関数）を呼び出した時、変数名の頭に$をつける

●３章：誤解されない名前
filter:選択したのか除外したのか曖昧
clip:用途に応じてremove, truncateなどにしたほうがいい
限界値を含む時は、MIN,MAXを使う。 LIMITは曖昧
範囲指定ではfirst と last
包含、排他的範囲にはbeginとend
ブール値の名前：肯定形にした方がいい。 disabled_ssl > use_ssl

●４章：美しさ
・読み手が慣れているパターンと一貫性のあるレイアウト
改行文字制限で似たコードが崩れないように注意
縦の線をそろえる：変数宣言, csvの列項目そろえなど
・似ているコードは似ているように見せる
順番を他の場所と揃える。フォームに入力順など・・・
・関連するコードをまとめてブロックにする
　コードを内容ごとに段落にする

●５章：コメントすべきことを知る
書き手の意図を読み手に知らせる
・コードからすぐわかることは書かない
・コメントのためのコメントは書かない：もっと大切なことに書き直す
・ひどい名前はコメントをつけずに名前を変える
　DeleteRegistry > ReleaseRegistoryHandle : 実際のレジストリは変えない処理の変更
・コードのコメント、考えの記録は重要
・コードの欠陥のコメント：todoリストにする
・質問されそうな処理にコメント
・ハマりそうな罠を告知
・全体像のコメント

●６章：コメントは正確で簡潔に
どうすればコメントを正確で簡潔に書けるか
・曖昧な代名詞をさける。それやこれが何を指しているかわからない
・歯切れの悪い文章を磨く
・関数の動作を正確に記述
　行数を返す＞　改行文字('\n')を数える
・実装の実例で示す
・Python: Connect(10, False) > Connect(timeout = 10, use_encryption = False)
・情報密度の高い言葉を使う>コメント簡潔

●第二部：ループトロジックの単純化

●７章：制御フローを読みやすくする
・if(obj = NULL) はif(obj == NULL)のバグの可能性 if(NULL == obj)にしてバグ回避
・条件は否定形より肯定形を使う
　ただし、否定形で関心や注意を引く場合は、先に処理
・通常のif文と三項演算子の使い分け
・do/whileループを避ける
・関数から早く返す：return文
・悪名高きgoto
・ネストを浅くする
可読性が悪くなる構成要素
・スレッド
・シグナル・割り込みハンドラ
・例外
・関数ポインタと無名関数
・仮装メソッド

●８章：巨大な式を分割する
・要約変数：式を変数に代入すると、変数名で説明を読み取れる
・ド・モルガンの法則で式を分離：notを分配してand/orを反転：見やすい式に変える
・ブール演算による短絡評価の組み合わせで複雑なロジックになってしまう
　＞頭がいいコードでも、あとになったら読みにくい

●９章：変数と読みやすさ
変数を適当につかうとプログラムが理解しにくくなる
・変数が多いと追跡が難しくなる
・変数のスコープが大きいとスコープを把握する時間が長くなる
・変数が頻繁に変更されると現在の値の把握が難しくなる

●第３部：コードの再構成

●１０章：無関係の下位問題を抽出する
下位レベルの問題を抽出し別の関数に抜き出して、高レベルの問題に集中できるようにする
再利用できる汎用コードをたくさんつくる
既存のインタフェースを簡潔に：ラップ関数も活用
やりすぎに注意：細かく関数を整備しすぎて細かい関数を順次追っていくのは大変

●１１章：一度に一つのことを
コードは一つずつタスクを行うようにしなければならない

●１２章：コードに思いを込める
・コードの動作を簡単な言葉で説明
・その中で使ってるキーワード、フレーズに注目
・その説明に合わせてコードを書く

●１３章：短いコードを書く
全てをかね揃えようと（過剰に）して膨大なコードを追加するより、そこそこパフォーマンスが出て簡潔なコード
＞結果を出すのに過剰な正確性を求めすぎている
標準ライブラリで事足りる処理かどうかの判断

●第４部：選抜テーマ

●１４章：テストと読みやすさ
テストを読みやすく保守しやすいものにする
エラーメッセージを読みやすくする
テスト：コードを検証する完璧な入力値１つより、小さなテストを複数作る方が簡単で、効果的で、読みやすい
テストしやすいようにコードも設計:やりすぎは注意
テスト関数に説明的な名前をつけて、何をテストしているか明らかにする

●１５章：「分/時間カウンタ」を設計・実装する
・速度とメモリ使用量の問題、柔軟性、高パフォーマンス化

●付録：あわせて読みたい
高品質のコードを書くための書籍の紹介

以上

へポスト