リーダブルコード

1. リーダブルコード
読み易いコードの書き方

2. リーダブルコード
• Dustion Boswell,
Trevor Foucher 著
• 角征典 訳
• 1-2週間で読める
• 他の書籍より読み易い
のでオススメ

3. リーダブルコードとは？
• リーダブルコード、つまり読み易いコード
• 読み易いと何がいいの？
• 他人が最短時間で理解できるようになる
(他人とは半年後の自分も含む)

4. 理解とは？
• 仕様がわかる
• バグがわかる
• 変更方法がわかる
• 他との連携する方法がわかる

5. 理解しやすいコードの
書き方

6. 表面上の問題

7. ネーミング

8. 名前に情報を詰め込む
• 明確な単語を選ぶ
Getじゃなくてfetchとかdownloadとかにする
例）send deliver, dispatch, distribute
find search, extract, locate
start launch, create, begin, open
make create, set up, build, generate, add, new

9. 汎用的な名前は避ける
• tmpとかresultとか
• でもローカル変数で使う場所が狭ければ
使ってもいいよ！
• ループのイテレータとかはi・j・kでOK

10. 名前に情報を追加する
• time -> time_ms
• size -> size_mb

11. 名前の長さ
• スコープが小さければ、短い名前でよい

12. 名前のフォーマット(例
• kConstantName 定数
• CONSTANT_NAME マクロ
• ClassName クラス
• methodName メソッド
• variable_name 変数

13. 誤解されない名前（例
• min, max 限界値を含む
• first, last 範囲指定
• begin, end 包含、排他的範囲（endは含まれない
• bool isやhasをつける、否定型にしない
• get getは軽量アクセサである
getで重くなるような計算してはいけない

14. 美しさ

15. 余白、配置、順序

16. 余白
• インデント、空行によってブロックや段
落を整える（縦のラインを意識
• 論理的な区切りができる

17. 配置
• 同様の処理はシルエットを える
• メソッドを使って える
DRY化にもなる

18. 順序
• 順序は変えない
• A・B・Cとあった情報をB・C・Aにして
はいけない
• 一貫性が大事

19. コメント

20. コメントすべきこと

21. コメントすべきでは"ない"こと
• コードからわかることを書かない
• コメントのためのコメントを書かない
例）関数には必ずコメントを書かなければならない
// 名前を取得する ←意味がない
getName();
• ひどいコードの場合はコメントを書くより修正する

22. 自分の考えを記録する
• 映画のコメンタリーのようなもの
• コードを書いた時の背景や理由がわかる
• Why, How, Whatは特にこだわらなくて
もよい

23. 欠陥をコメントする
• // TODO：もっと高速化が必要
• // XXX：破壊的なメソッド！

24. 全体像をコメントする
• // このクラスはキャッシュです、システ
ムのことは関知しません
• // このクラスはファイルシステムに関す
るヘルパー関数を提供します

25. 要約をコメントする
• // ロックを取得
• // ユーザの情報をDBから読む
• // 情報をファイルに書き出す
• // ロックを開放

26. 正確で完結に

27. 完結に書く
• 領域に対する情報の比率が高くなければ
いけない

28. 代名詞はさける
• それ、これ
⇒ データを、価格を

29. 正確に記述する
• // 行数を返す
⇒ // 改行文字（n)を数える

30. 実例を使う
• // 例) Strip("abba/a/ba", "ab") => "/a/"

31. コードの意図を書く
• // 逆順で表示する
⇒ // 値段の高い順に表示する

32. ループとロジックの単純化

33. 制御フロー

34. 自然に書く
• if( length > 10 ) ←こっちのほうがいい
if(10 <= length)
• 左側：調査対象の式、変化する
• 右側：比較対象の式、あまり変化しない

35. if/elseブロックの書き方
• 否定形よりも肯定形
• 単純な条件を先に
• 関心を引く条件や目立つ条件を先に

36. 三項演算子
• 使うならわかりやすく

37. 関数から早く返す
• ガード節とか

38. ネストは浅く
• 早めに返す、内部のネストを関数化する

39. 式の分割
• 巨大な式を飲み込みやすい大きさに

40. 説明変数を導入する
• line.split(":").[0] == “Bob”
• user_name = line.split(":").[0];
user_name == “Bob”

41. ロジックを書き直す
• ド・モルガンの法則を使う
• 反対にすると、簡単になるかもしれない
• 重なる範囲を探す
⇒ 重ならないケースを探す

42. 変数と読みやすさ
• 変数を削除する
• 変数のスコープを縮める
• 変数は一度だけ書き込む
変数がどこで書き変えられたかを追跡するのは難しい
constやfinalでイミュータブルにするのは有効

43. コードの再構成

44. 無関係の下位問題
1. このコードの高レベルな目標は何かを見定める
2. 高レベルの目標に直接関係あるのか、無関係の
下位問題なのか見分ける
3. 無関係の下位問題を抽出する

45. 無関係の下位問題
• プロジェクト固有のコードから汎用コードを
分離すること
• ヘルパーをたくさん作る

46. 1度に1つのことを
• コードは1つずつタスクを処理しなけれ
ばならない
• タスクは小くできる
• そのコードで行なわれているタスクを列
挙し、分割し、適用させる

47. コードに思いを込める
• ロジックを簡単な言葉で説明する、それ
に合せてコードも書く

48. 短いコード

49. 質問と要求の分割
• 「その機能の実装について悩まない、
きっと必要ないから」
• 過剰な機能を抑えて、単純に実装する
• 全てのプログラムがあらゆる入力に対応
し、高速である必要はない

50. コードを小く保つ
• 定期的に見直す

51. ライブラリを使う
• 平均的なエンジニアが1日に書く"出荷用"のコー
ドは10行
• 設計・デバッグ・修正・文章・最適化・テストな
どのコストを含んだ値
• なるべくコードを再利用をする

52. Unixのコマンドを使う
• 実装するよりコマンドを直接呼んだ方が
いい
• awkとかegrepとか便利

53. テスト

54. テストも読み易く
保守しやすいものにする
• テストが複雑だと…
• 本物のコードを修正しなくなる
• テストを追加しなくなる

55. 最小のテストを作る
• 入出力のテストなどは1行でかけると良い

56. 独自のミニ言語を実装する
• テスト用に実装しちゃう
• DSLとか

57. エラーメッセージ
• エラーが発生しました！
じゃわからない
• エラー時の変数の値を出力すると良い
• assertを書き変えてカスタマイズするの
もアリ

58. テストの入力値
• コードをテストする最も単純な入力値の
組み合せにする
checkScore("999.97, -246, 3", )
checkScore("1e100, -1, 2"）

59. 1つの機能で複数のテスト
• 小さなテストを複数作る
assert(“Barack”, person.firstName)
assert(“Obama”, person.familyName)
assert(“male”, person.sex)

60. テストの名前は適切に
• テストからしか呼ばれないので、冗長で
説明的でよい

61. やりすぎ注意
• テストのために本物のコードを犠牲にする
• テストのカバレッジを100%にしないと気が
すまない
90%でよい、残りの10%はUIやどうでもい
いエラーである

62. まとめ

63. • ネーミング
わかりやすい名前をつける
• 分割
飲み込みやすい大きさに分割
• コメント
そのコードの狙いは、なぜそのコードを書いたのかを書く
• スタイル（見た目）
インデントやブロックを えて見た目で理解できるように

64. 理解しやすいコードを書こう！

65. END