#概要
前回の続きリーダブルコード~より良いコードを書くために~(2/3)
#11.一度に一つのことを
例)1関数内:オブジェクトを生成して、データを綺麗にして、入力をパースして.....多すぎ!
-
コードはひとつずつタスクを行うようにする(関数に限らずクラス等も)
- 1.コードが行っているタスクを全て列挙する(書き出す)
- 2.その中で使っているキーワードやフレーズに注目する =>分割する下位問題かどうか分かる
- 3.タスクをできるだけ異なる関数に分割する
#12.コードに思いを込める
-
「おばあちゃんに分かるように説明できなければ本当に理解したとは言えない - アルバート・アインシュタイン」
- 1.コードの動作を簡単な言葉で同僚にも分かるように説明する
- 2.その説明の中に合わせてコードを書く
-
コードを簡潔に書くためにライブラリを知る
- わざわざデバッグの手間かけて自前で作るよりもライブラリがあったらそっちを使う方が安全かつ楽
-
技法「ラバーダッキング」
- 問題を物に話しかけることで、話しているうちに頭の中で問題が整理され、解決法が導かれる
例)デバッグに悩む学生が問題を声に出して説明するだけで、学生は解決策が見つかった
#13.短いコードを書く
-
最も読みやすいコードは何も書かれていないコード
- 「その機能の実装についてそんな悩まないで、きっと必要ないから」
- 最も簡単に解決問題を解決できるような要求を考える
-
汎用的なユーティリティコードを作って重複コードを削除する(10.無関係の下位問題の抽出 参照)
-
未使用のコードや無用な機能を削除する
-
プロジェクトをサブプロジェクトに分割する
-
コーディングするよりもUnixなどOS(その他)がもつツールを使おう
- プログラムを書かなくてもコマンド一発で解決できる場合もある
#14.テストと読みやすさ
-
テストを読みやすくする
- 大切でない詳細はユーザーから隠す
-
エラーメッセージを読みやすくする
- 変数の値も同時に出力するようにあらかじめしておく
- よりよいassert()を使う
// Boost C++ライブラリを使って...
BOOST_REQUIRE_EQUAL(output,expected_output);
// ↑テストに失敗するとエラーメッセージ & 変数の中身も表示してくれる
- テストの適切な入力値を選択する
- 最も単純な入力値の組み合わせ
// 良くない例)
CheckScore(0,1,4,-90000) // <= -90000とか何の意味があるの?
CheckScore(0,1,4,-1) // <= 「任意のマイナス値をテスト」するなら"-1"で十分
- テストの機能に名前をつける
- 「テストするクラス」や「テストする関数」、「テストする状況やバグ」
- テストの名前は長くなっても構わない(もしろ詳細が分かる方が良い)
例) Test_関数名_状況(){}
- テストに優しい開発 = テストを意識開発
- 例えばテスト駆動開発(TDD)...本物のコードを書く前にテストを書くプログラミング手法
#おわりに
※当初では2部構成で 「リーダブルコード~より良いコードを書くために~」をまとめる予定だったが以外と後半部分の量が多かったので,3部構成となってしまいそうです．ごめんなさい．
本記事はほんとにざっくりとまとめているので深く理解するにはやっぱ書籍(リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック)を買うことをオススメします．
#おまけ
書籍内には下記の書籍もいくつか紹介/推奨していた
1.Code Complete 第2版<上><下>-完全なプログラミングを目指して-
2.リファクタリング-プログラムの体質改善テクニック
3.プログラミング作法
4.達人プログラマー - システム開発の職人から名匠への道
5.Clean Code-アジャイルソフトウェア達人の技