より分かりやすくメンテナンス性の高いプログラムを書くための鉄則集。先輩が後輩を指導するようなわかりやすい語り口と、明日から使える実践的なサンプルが多数ある点がGoodなのです。若手のころに出会っていればよかった。SEは必読です。
↑気になったらここからポチっと（買ってくれるとお小遣いが入ります）↑
↓気になったらここからポチっと（買ってくれるとお小遣いが入ります）↓
↑気になったらここからポチっと（買ってくれるとお小遣いが入ります）↑
この本を読むとわかること
理解しやすいコード
- 他人が最短時間で理解できるコードが最良のコード
- 短いコードが必ずしも優れているとは限らない
- 長いけど読みやすいコード＞＞短く複雑なコード
表面上の改善
- 名前に情報を詰め込む
- 変数や関数には汎用的な単語は避け、内容が一目でわかる明確で具体的な名前を
- よりメンテナンス性の高いループ変数（i,j,k）の名付け方
- 変数・関数の名前は読み手への「コメント」と心がける
- グローバル変数ほど明確に、ローカル変数は簡素でもOK
- 誤解されない名前
- 関数の名前はその動作を明快に
- 変数の名前も概要だけではなく詳細が分かるように
- 否定形の名前は使わない
- 最善の名前とは第三者が見ても誤解しない「明確で一意な名前」
- 美しさ
- コードの見た目を美しくすることで得られる多くの副次効果
- 「縦の線」を意識することによるタイプミス削減・可読性向上
- 変数や関数をランダムではなく「意味のある並べ方」へこだわることの大事さ
- 処理のブロックごとに要約コメントを追加してブラックボックス化を防ぐ
- コメントすべきことを知る
- 優れたコード＞＞ひどいコード＋優れたコメント
- 優れたコメントとは「プログラマーの考えやそのようにした背景の記録」
- コメントは正確で簡潔に
- 関数のコメントは「動作を正確に記述」
- 冗長な文章よりも、入力に対する出力例を示すコメントを
- コーディングしている時（一番そのコードに集中しているとき）の考え・意図を記述する
ループとロジックの単純化
- 制御フローを読みやすくする
- 条件式の左右（if a>bなど）の明確な使い分け方
- 条件判定で否定形を避ける
- コードの行数を身近宇kするよりも、第三者が理解するのにかかる時間を短くする
- forループやwhileループと比較してdo/whileループが読みにくい理由
- 悪名高きgoto文が唯一許される場合
- 深いネストが理解しにくいのは判定条件の理解だけでなく、「ネストにおける現在地」を常に確認しなければならないから
- 既存のコードに新しいコードを追加する際の鉄則
- 巨大な式を分割する
- 分かりづらい式を分割するには式を表す「説明変数」を使って分割
- 変数が複数入った分かりにくい判定式はその式の意図を表す「要約変数」でくるむ
- 複雑なロジックを単純なロジックに組み替えるための逆転の発想
- 変数と読みやすさ
- ループを抜けるかを制御するフラグなど「制御フロー変数」はうまくプログラミングすれば排除できる
- 変数の「スコープ」はなるべく小さく、グローバル変数は避ける
- メソッドはできるだけstaticに
- JavaScriptでは変数に「var」をつけ忘れるとグローバルスコープになるので注意
コードの再構成
- 無関係の下位問題を抽出する
- ループの中で使われる複雑な式や繰り返し使われる式は関数化として切り出すことで可読性と保守性を向上
- 小さく独立した関数は保守性が高い
- そのプログラムの主目的ではない処理を関数化して切り出すことで本質的なロジックに集中できる
- 一度に1つのことを
- 1ブロックのプログラムで行うのは1つの処理だけに
- 「プログラムで行っていることを正確に説明」できることを念頭に置いたコーディング
- コードに思いを込める
- 何をしようとしているのか説明・思考する順番でコードを記述
- 短いコードを書く
- 初期構築以降の維持・保守によってコードが大きくなると改修コストも大きくなる
- コードをできるだけ小さく軽量に維持することが大事
- 標準ライブラリに親しみ、やろうとしていることが標準ライブラリで実装済みでないか確認
選抜テーマ
- テストと読みやすさ
- コードを検証する完璧な1つの入力値でテストするより、観点ごとに小さなテストを複数作る
- テストを意識した「テストしやすいコード」を設計
- テストの難しいコードの特徴と設計の問題
↓気になったらここからポチっと（買ってくれるとお小遣いが入ります）↓
