i_amaiの雑記

お金稼ぎが目的の、クソつまんないブログです

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

どうも、こんにちは。

以下の本を読みました。

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

諸事情によりリンク無しです。そのうち差し替えますので、ご容赦ください。

今回は書評を書いてみたいと思います。ちなみに、人生初書評です。お手柔らかに(?)。

読もうと思った背景

プログラミングを勉強し始めて1年経ったタイミングで、会社の同僚にプログラミングに関する講義をすることになり、理論武装余儀なくされたため。

個人的にはとくにユニットテストを(自分を含めた)社内に流行らせたくて、ユニットテストの書き方が具体的に載っている本を探していました。

感想

私はどちらかと言えば普段から「分かりやすいコードってどんなだろう?」と考えながら書いている方だと思っているんですが、「分かりやすいコードとはこんなコードだ!」と誰かに教わったわけではないので、曖昧なマイルールみたいなものが、まあ多くてですね。

たとえば、Excel VBAで、変数の名前に該当セルの番地を使ったり、使うフラグの数に応じて順番に、f3とかf7みたいなのを割り当てちゃう人がいたとして、「そ、それはあかん!」って話はするんですけど、「じゃあどうすりゃいいの?」って聞かれたら、ちょっと困っちゃうんですね。気持ち悪さをきちんと言語化できないというか(まあこの例だと分かりやすいですけど)。

「このコードはなぜ分かりづらいのか?」

であるとか、

「このコードはどうしたら『分かりやすいコード』になるのか?」

といった問に対する答えが、なんか主観的で、曖昧になりがちなんですよね。

諭し方が主観的だと、人って言うこと聞いてくれないじゃないですか。

そこらへんをきちんと、曖昧にせずに、(ちょっとお節介な先輩が)理屈っぽく教えてくれるのがこの本、という感じでした。


この本で一貫してキーとなる考えがありまして。

コードは他の人が最短時間で理解できるように書かなければいけない。

「他の人」には、「将来の自分」も含まれていて、これを本の中では、「読みやすさの基本定理」と呼んでいます。

これさえ覚えておけば、後はときどき立ち止まってコードを眺めてみて、「他の人にとって読みやすくなってるかな?」と考えてみる。必要に応じて、この本を開いて助言を得る。

そんなスタンスで、いけそうな気がしてきました。

あと、ユニットテストの書き方ですが、C++のサンプルコードが「悪い例」→「良い例」→「さらに良い例」とリファクタリングされていくのが参考になったほか、

テストが何をしているかは1つの文で記述できる。

という一文が印象的でした。

どうも、テストを書かないできた私のような人間からすると、テストの実装を難しく考えがちなところがあって。ポンと背中を押されたような気持ちです。テスト書こー。

調べた言葉

ベクタとスワップ p.64

vector = ベクタ = ベクトル

ベクタはC++で使われる動的配列。動的配列とはサイズを自由に変更できる配列のこと。

スワップは2つの値を入れ替える。

vector
a quantity having direction うんたらかんたら
swap
an act of exchanging one thing for another.

do/while ループ p.90

do { 文; } while (継続条件式);

まず文を実行してから、継続条件の判定を行う。継続条件式が真である間、文を繰り返し実行する。

ガード節とクリーンアップコード p.91

ガード節はreturn, continue, breakで早めに条件やループを抜ける。ネストを減らすメリットがある。

クリーンアップコードは、メモリーファイルシステムに残ったデータ構造を掃除するために書かれるコード。

デストラクタ p.92

C++で、コンストラクタなどでメモリ内に確保したリソースを開放するための処理。

destructor
a furnace(焼却炉) or oven for the burning of refuse

continue文 p.96

for, while, do/while ループの中で、処理を(for文等のブロック終了直前まで)スキップさせるために用いる。通常if文と併用される。

スレッド p.97

thread of executionの略。実行の脈略。CPU利用の単位。

コンピュータは擬似的に同時処理を行うために、ごく短い時間ごとに動かすスレッドを切り替えて、あたかも同時に複数のスレッドが動いているように見せかける。

シグナル/割り込みハンドラ p.97

シグナルとは、プロセス間通信の一種。たとえばCtrl + Cを押下すると対象プロセスにシグナルが送られる。

ハンドラとは、シグナルをプロセスが受信したときにプロセスが行う動作のこと。

例外 p.97

例外処理とは、下位の処理で異常(例外)があり継続不能等に陥ったとき、呼出し元の上位の処理に制御を返し安全な状態になるよう回復処理をすること。

関数ポインタ p.97

ポインタはメモリの番地を参照先にするものだが、関数ポインタでは参照先を関数にする。

仮想メソッド p.97

メソッドの動的呼出し。

C#では、virtualで定義したメソッドをoverrideで再定義することができる。

ここら辺、ちょっと調べたけどよく分からん。

DRY原則 p.106

Don't Repeat Yourselfの略。

同じ知識を2箇所以上に記述すると、当該1箇所の変更の際に他の部分も変えなければならない。結果、矛盾が発生しやすくなるし、データの信頼性が損なわれる。

要はRDBの正規化みたいなものだ。たぶん。

break文 p.115

最も内側のfor文、while文、do/while文から脱出する。

記憶が曖昧だったので調べた。

イミュータブル p.124

unchanging over time or unable to be changed.

不変。対義語はmutable。

forループの条件にtrueを使う p.126

for文は、下記条件式の値がtrueな限りループし続ける、というもの。

for (初期化式; <b>条件式</b>; 変化式){
  実行する文;
}

で、条件式にtrueがそのまま入っていると、{}内で処理が返る等しない限りループし続けることになる。

本書のp.126で使われていたけど、不要なバグを生みそうな気がする。

ビジネスロジック p.144

そのシステム固有の処理…を、ふんわり表現したもの、らしい。

英語版Wikipediaにはこうある。

business logic or domain logic is the part of the program that encodes the real-world business rules that determine how data can be created, stored, and changed.