「リーダブルコード」を 2,023 年 04 月 23 日に読んだ。
目次
メモ
p12
シソーラス (類語辞典) を使って調べよう。 友達にもっといい名前がないかと聞いてみよう。
英語は豊かな言語だから、選べる単語はたくさんあるはずだ。
p15
イテレータが複数あるときには、インデックスにもっと明確な名前をつけるといいだろう。
i・j・k ではなく、説明的な名前 (club_i・members_i・users_i) にするのだ。
あるいは、もっと簡潔なもの (ci・mi・ui) でもいいだろう。
こうすればバグが目立ちやすくなる。
頭文字と省略形 p24
プログラマは頭文字や省略形を使って名前を短くすることがある。
例えば、クラス名を BackEndManager じゃなくて BEManager にしたりする。
このように情報を圧縮すると混乱の元になるだろうか?
ぼくたちの経験からすると、プロジェクト固有の省略形はダメだ。
新しくプロジェクトに参加した人は、暗号みたいに見えて怖いと思うだろう。
しばらくすると、それを書いた人ですら暗号みたいで怖いと思うようになる。
新しいチームメイトはその名前の意味を理解できるだろうか?
理解できるなら問題ない。
プログラマは、 evaluation の代わりに eval を使う。
document の代わりに doc を使う。
string の代わりに str を使う。
だから、新しいチームメイトも FormatStr() の意味は理解できる。
でも、BEManager の意味は理解できない。
3.4 範囲を指定するときは first と last を使う p32
start は適切な名前だ。
でも、 stop は複数の意味に解釈できる。
包含的な範囲を表すのであれば (終端を範囲に含めるのであれば)、 first と last を使うのがいい。
3.5 包含排他的範囲には begin と end を使う p33
ここに使う仮引数の名前は何がいいだろうか?
プログラミングの命名規約では、包含/排他的範囲に begin と end を使うことが多い。
でも、endは少しあいまいだ。
例えば、「本の終盤 (the end of the book)を読んでいる」の「end」は包含的だ。
残念ながら英語には「ちょうど最後の値を超えたところ」を意味する簡潔な言葉がない。
begin と end の対はイディオムになっている
(少なくともC++の標準ライブラリではこれが使われている。また、配列がこのように「スライス」されることも多い) ので、これが最善の選択と言える。
5.2 自分の考えを記録する p60
何をコメントすべきでないかはわかった。
それじゃあ、何をコメントすべきかを考えていこう(みんな考えてないことが多いよね)。
優れたコメントというのは「考えを記録する」ためのものである。
コードを書いているときに持っている「大切な考え」のことだ。
7.2 if/else ブロックの並び順 p86
・条件は否定形よりも肯定形を使う。例えば、 if (!debug) ではなく、if (debug) を使う。
・単純な条件を先に書く。 if と else が同じ画面に表示されるので見やすい。
・関心を引く条件や目立つ条件を先に書く。
8.3 ド・モルガンの法則を使う p101
電気回路か論理学を学んだことがあれば、ド・モルガンの法則を覚えているかもしれない。
論理式を等価な式に置き換える方法は2つある。
この法則が覚えにくいようであれば、「 not を分配して and/or を反転する」 (逆方向は「 not をくくりだす」) と覚えればいい。
この法則を使えば、論理式を読みやすくできる。
10.6 既存のインタフェースを簡潔にする p137
誰もがキレイなインタフェースを提供するライブラリが好きだ。
引数は少なくて、事前設定も必要なくて、面倒なことをしなくても使えるライブラリ。
インタフェースがキレイだとコードが優雅に見える。
簡潔で、しかも強力だ。
インタフェースがキレイじゃなくても、自分で「ラップ」関数を作ることができる。
例えば、 JavaScript でブラウザのクッキーを扱うのはすごく残念な感じだ。
クッキーは名前と値のペアになっているはずなのに、ブラウザが提供するインタフェースには、
以下のような構文の document.cookie という文字列しかない。
ここでの教訓は「理想とは程遠いインタフェースに妥協することはない」ということだ。
自分でラッパー関数を用意して、手も足も出ない汚いインタフェースを覆い隠すのだ。
12.4 まとめ p165
本章では、プログラムのことを簡単な言葉で説明する技法について説明した。
説明することでコードがより自然になっていく。
この技法は思っているよりも簡単だが非常に強力だ。
説明で使っている単語やフレーズをよく見れば、分割する下位問題がどこにあるかがわかる。
この「簡単な言葉で説明する」手法は、コードを書くこと以外にも適用できる。
例えば、ある大学の計算機センターにはこんな方針があった。
プログラムのデバッグに悩む学生は、部屋の隅に置かれたテディベアに向かって最初に説明しなければいけないのである。
驚くべきことに、問題を声に出して説明するだけで、学生は解決策が見つかるのだ。
この技法は「ラバーダッキング」とも呼ばれている。
問題や設計をうまく言葉で説明できないのであれば、何かを見落としているか、詳細が明確になっていないということだ。
プログラム(あるいは自分の考え)を言葉にすることで明確な形になるのである。
14.8 テストに優しい開発 p193
コードにはテストしやすいものとそうでないものがある。
テストしやすいコードには、明確なインタフェースがある。
状態や「セットアップ」がない。
検査するデータが隠されていない。
あとでテストを書くつもりでコードを書くと、おもしろいことが起きる。
テストしやすいようにコードを設計するようになるのだ!
このようにコードを書いていけばいいコードが書けるようになる!
テストに優しい設計をすれば、振る舞いごとにうまく分割されて、自然にコードが構成されていく。
テスト駆動開発 p193
テスト駆動開発 (TDD: Test Driven Development) は、本物のコードを書く前にテストを書くというプログラミング手法だ。
コードを書いてからテストを書くよりもコードの品質が飛躍的に向上すると言われている。
よく議論になる話題なので深追いはしないけど、少なくともテストのことを気にしながらコードを書けば、コードがよくなるのはそのとおりだと思う。
TDD を採用するかどうかに関わらず、他のコードをテストするコードはできあがる。
本章の目標は、そのテストを読み書きしやすくすることだ。
14.9 やりすぎ p195
場合によっては、テストに集中しすぎてしまう可能性もある。
いくつか例を示そう。
・テストのために本物のコードの読みやすさを犠牲にしてしまう。
本物のコードをテストしやすいように設計するには、両者に利点がなければいけない。
本物のコードは単純で疎結合なものにする。
テストは読み書きしやすくする。
テストをしやすくするために、本物のコードにゴミを入れてはいけない。
・テストのカバレッジを100%にしないと気が済まない。
コードの90%をテストするほうが、残り10%をテストするよりも楽である。
最後の10%にはユーザインタフェースやどうでもいいエラーケースが含まれている。
その部分はバグのコストが高くないので、テストが割に合わない。
現実的には、カバレッジが100%になることはない。
もしも100%になっているのだとしたら、バグを見逃しているか、機能を実装していないか、
仕様が変更されたことに気づいていないかのどれかだ。
高品質のコードを書くための書籍 p218
「Code Complete 第2版 〈上〉〈下〉 完全なプログラミングを目指して」
スティーブ・マコネル著、クイープ訳、日経BPソフトプレス
コードの品質などソフトウェアの構築に関するあらゆる側面について、緻密でよく調査された学術書。
「リファクタリング プログラムの体質改善テクニック」
マーチン・ファウラー著、児玉公信、平澤章、友野晶夫、梅沢真史訳、ピアソンエデュケーション
漸進的なコードの改善に関する名著。
さまざまなリファクタリング手法の詳細なカタログとコードを破壊せずに変更を加える手順が載っている。
「プログラミング作法」
ブライアン・カーニハン、ロブ・バイク著、福崎愛博訳、アスキー
デバッグ・テスト・移植性・パフォーマンスなどのプログラミングに関する話題と豊富なサンプルコードが載っている。
「達人プログラマー システム開発の職人から名匠への道」
アンドリュー・ハント、デビッド・トーマス著、村上雅章訳、ピアソンエデュケーション
プログラミングやエンジニアリングの優れた原則がたくさん集められていて、短い考察と一緒に載っている。
「Clean Code アジャイルソフトウェア達人の技」
ロバート・C・マーティン著、花井志生訳、アスキー・メディアワークス
本書と似ている (こちらは Java 専用になっている) けれど、エラー処理や同時並行性などについても考察されている。