book

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック

by Dustin Boswell, Trevor Foucher, 角征典

June 2012

Beginner to intermediate

260 pages

2h 35m

Japanese

O'Reilly Japan, Inc.

Read now

Unlock full access

面白いと、読みやすいは、違うんだよ？やらんもんは…勝たれへん！！謝辞
本書について本書の読み方ライセンスについてサンプルコードの使用謝辞
1.1　「優れた」コードって何？1.2　読みやすさの基本定理1.3　小さなことは絶対にいいこと？1.4　「理解するまでにかかる時間」は競合する？1.5　でもやるんだよ
2.1　明確な単語を選ぶもっと「カラフル」な単語を探す2.2　tmpやretvalなどの汎用的な名前を避けるtmpループイテレータ汎用的な名前のまとめ2.3　抽象的な名前よりも具体的な名前を使う例：DISALLOW_EVIL_CONSTRUCTORS例：--run_locally2.4　名前に情報を追加する値の単位その他の重要な属性を追加する2.5　名前の長さを決めるスコープが小さければ短い名前でもいい長い名前を入力するのは問題じゃない頭文字と省略形不要な単語を投げ捨てる2.6　名前のフォーマットで情報を伝えるその他のフォーマット規約2.7　まとめ
3.1　例：filter()3.2　例：Clip(text, length)3.3　限界値を含めるときはminとmaxを使う3.4　範囲を指定するときはfirstとlastを使う3.5　包含／排他的範囲にはbeginとendを使う3.6　ブール値の名前3.7　ユーザの期待に合わせる例：get*()例：list::size()3.8　例：複数の名前を検討する3.9　まとめ

4.1　なぜ美しさが大切なのか？4.2　一貫性のある簡潔な改行位置4.3　メソッドを使った整列4.4　縦の線をまっすぐにする整列すべきなのか？4.5　一貫性と意味のある並び4.6　宣言をブロックにまとめる4.7　コードを「段落」に分割する4.8　個人的な好みと一貫性4.9　まとめ
5.1　コメントするべきでは「ない」ことコメントのためのコメントをしないひどい名前はコメントをつけずに名前を変える5.2　自分の考えを記録する「監督のコメンタリー」を入れるコードの欠陥にコメントをつける定数にコメントをつける5.3　読み手の立場になって考える質問されそうなことを想像するハマりそうな罠を告知する「全体像」のコメント要約コメント5.4　ライターズブロックを乗り越える5.5　まとめ
6.1　コメントを簡潔にしておく6.2　あいまいな代名詞を避ける6.3　歯切れの悪い文章を磨く6.4　関数の動作を正確に記述する6.5　入出力のコーナーケースに実例を使う6.6　コードの意図を書く6.7　「名前付き引数」コメント6.8　情報密度の高い言葉を使う6.9　まとめ
7.1　条件式の引数の並び順7.2　if/elseブロックの並び順7.3　三項演算子7.4　do/whileループを避ける7.5　関数から早く返す7.6　悪名高きgoto7.7　ネストを浅くするネストが増える仕組み早めに返してネストを削除するループ内部のネストを削除する7.8　実行の流れを追えるかい？7.9　まとめ
8.1　説明変数8.2　要約変数8.3　ド・モルガンの法則を使う8.4　短絡評価の悪用8.5　例：複雑なロジックと格闘するより優雅な手法を見つける8.6　巨大な文を分割する8.7　式を簡潔にするもう1つの創造的な方法8.8　まとめ
9.1　変数を削除する役に立たない一時変数中間結果を削除する制御フロー変数を削除する9.2　変数のスコープを縮めるC++のif文のスコープJavaScriptで「プライベート」変数を作るJavaScriptのグローバルスコープPythonとJavaScriptのネストしないスコープ定義の位置を下げる9.3　変数は一度だけ書き込む9.4　最後の例9.5　まとめ
10.1　入門的な例：findClosestLocation()10.2　純粋なユーティリティコード10.3　その他の汎用コード思いも寄らない恩恵10.4　汎用コードをたくさん作る10.5　プロジェクトに特化した機能10.6　既存のインタフェースを簡潔にする10.7　必要に応じてインタフェースを整える10.8　やりすぎ10.9　まとめ
11.1　タスクは小さくできる11.2　オブジェクトから値を抽出する「一度に1つのタスク」を適用するその他の手法11.3　もっと大きな例さらなる改善11.4　まとめ
12.1　ロジックを明確に説明する12.2　ライブラリを知る12.3　この手法を大きな問題に適用する解決策を言葉で説明する手法を再帰的に適用する12.4　まとめ
13.1　その機能の実装について悩まないで——きっと必要ないから13.2　質問と要求の分割例：店舗検索システム例：キャッシュを追加する13.3　コードを小さく保つ13.4　身近なライブラリに親しむ例：Pythonのリストとセットライブラリの再利用はなぜいいことなのか13.5　例：コーディングするよりもUnixツールボックスを使う13.6　まとめ
14.1　テストを読みやすくて保守しやすいものにする14.2　このテストのどこがダメなの？14.3　テストを読みやすくする最小のテストを作る独自の「ミニ言語」を実装する14.4　エラーメッセージを読みやすくするもっといいassert()を使う手作りのエラーメッセージ14.5　テストの適切な入力値を選択する入力値を単純化する1つの機能に複数のテスト14.6　テストの機能に名前をつける14.7　このテストのどこがダメだったのか？14.8　テストに優しい開発14.9　やりすぎ14.10　まとめ
15.1　問題点15.2　クラスのインタフェースを定義する名前を改善するコメントを改善する15.3　試案1：素朴な解決策このコードは理解しやすいか？読みやすいバージョンパフォーマンスの問題15.4　試案2：ベルトコンベヤー設計二段階ベルトコンベヤーの実装これで終わり？15.5　試案3：時間バケツの設計時間バケツの実装TrailingBucketCounterを実装するConveyorQueueの実装15.6　3つの解決策を比較する15.7　まとめ
高品質のコードを書くための書籍プログラミングに関する書籍歴史的記録
実際にやる実際にやるとぶつかること他の人に読んでもらうおさらい当たり前にする既存のコードを読みやすくする前にやること続けることが大事コードで伝える読みやすいコードがもっと当たり前であり続けるためにコミットメールのススメまずはあなたが読む添削コミットおさらい最後に

Content preview from リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック

11章一度に1つのことを

一度に複数のことをするコードは理解しにくい。例えば、オブジェクトを生成して、データをキレイにして、入力をパースして、ビジネスロジックを適用しているようなコードだ。これらのコードがすべて絡み合っていると、「タスク」が個別に完結しているコードよりも理解するのが難しい。

鍵となる考え

コードは1つずつタスクを行うようにしなければいけない。

別の言い方をすれば、本章はコードの「デフラグ」について説明している。以下の図は、デフラグの手順を示したものだ。左側には、さまざまなタスクを行なうコードを描いている。右側には、一度に1つのタスクを行うように再構成したコードを描いている。

「関数は一度に1つのことを行うべきだ」というアドバイスを聞いたことがあるかもしれない。ぼくたちのアドバイスもこれと似ている。でも、関数に限った話じゃない。もちろん、大きな関数は小さな複数の関数に分割したほうがいい。でも、関数のなかでコードを小さく構成することもできる。例えば、論理的な区分に分けてあげるのだ。 ...