『リーダブルコード』読みました。 [本]
前々から読もうとは思っていたんだけど、どうしようか迷っていた本。今回手に入れることができたのでレビューします。これは初心者よりも少しコーディングに慣れてきた人の方がすんなりと入っていく気がします。こう書けよ、と言われるよりか、自分のやっている悪癖を正す方がわかりやすいというか、実利がある気がするので。
ネタバレというか、内容を小出しにしていくよ。気になったら上のリンクからどうぞ。
手短に言うと、自分にも読む相手にもわかりやすいコードを書きましょう、と言う話。簡単なようでいて難しい。というのは、自分が読みにくいコードを書いていること自体を認識するところから始めないといけないから。
内容的にはプログラミングの構造とかは少し出てくるんだけど、いわゆるアーキテクチャやデザインパターンの話は出てこない。もっとプリミティブな根源的な問題というか、字面をどれだけ理解しやすいものにするかというものでした。要するに「コードを読んですぐわかる書き方をしよう」ということです。
そんなもん、個人の工夫でなんとでもなるだろ、とか、とりあえずコーディング規約に反していなければいいだろ、と言われればそうかも知れません。だけど、そこには自分を含め、後で読む人のための配慮というものが必要だろうということなんだろうなと思います。
例示として、C++、JavaScript、Python、Javaを使っているが、応用的なところがないので理解には問題ないとしているが、やっぱり知っていた方がいい。
と書かれてC++が全くな人はちょっと理解しづらい（ただ文字列を出しているだけなのに）。あとC++関係で、コピーコンストラクタとか代入演算子の再定義とか書いてあるんだけど、クラスのある他の言語を知っていても理解が辛い気はする。
なので、上の言語の三つくらいは軽くは知っていないとサラッと読めない。読み飛ばしてもいいけど、十分に理解しているとは言えない。まぁ面倒でもググって調べれば済むだけの話だけど、ネットがない出先ですんなり通読するのは難しいだろう。というか、今のようにWebを少し調べれば理解できる状態になったから成立する書物だろう。そうじゃなきゃ、各言語の初歩的な文法解説本が必要になってしまうしね。
読んでいると痛いことが結構書いてあるんだよね。はじめの方にあるんだけど、tmpとかretvalは変数名として内容が分からないからあまり良くないとか、身に染みることは結構ある。だから、初心者よりもある程度のボリュームを書いた中級者におすすめなのだ。知らずにやってしまう、どうしても面倒でやってしまう悪習のオンパレード。というほどでもないんだけど、それはよくやるけど分かりづらいでしょう、ということはかなりありますね。書いている人ほどやりがちなところがあるから、身を正すにはいい経験になるとは思いますよ。
読み終わって目次をサラッと見てみると、こんな感じ。
重要じゃなくても気になったものは入れてある。
・変数関数などの名前にわかりやすい情報を盛り込む。
・変数スコープは小さい方がいい。
・名前は誤解されないものを選ぶ。
・ノーテーションとか見た目は綺麗に保つ。
・コメントすべきことを知り正確で簡潔に。
・制御フローは深く複雑にしない。
・巨大な式は分割する。
・役に立たない一時変数は削除する。
・変数のスコープは言語によって微妙に違う。
・無関係の下位問題を汎用コードにする。
・散らばった同じタスクはまとめる。
・ライブラリを使って短いコードを書く
・テストを読みやすくて保守しやすいものにする。
・設計から考えて読みやすいものにする。
箇条書きにしてしまうと、何だこんなものかと思ってしまうのだけれど、例示されたコードがわかりやすくて秀逸だ。いろいろ言語はあるのだけれど、深入りしない限りは大体何をしようとしているのかは大体はわかるし、それを前提に書いてあるので、わかりづらい例も読みづらいことを意識しやすいものになっているし、それを改善したコードもどう変わったのかがわかりやすい。
それを例示するのは結構難しいことなんじゃないかと思う。それが色々な言語に渡っているならば尚更のことである。当然のことながら、上の箇条書きよりか内容はぜんぜん理解しやすい。
翻訳本のオライリーにしては、翻訳っぽくない読みやすさである。だけど、変数の付け方とか、日本人としてはすんなり入ってくるものではなかったりする。そこは翻訳うんぬんというものではないのだけれども、英語にして日本人がわかりやすいかどうかと言うのは一つのハードルであると思う。Depreciationと書いてもすぐにわかる人いないと思うけど、ローマ字でGenkashokyakuとか書いた方が日本人には確実ですしね。正直長くて読みづらいけど、意味の通りから言うと間違いがない。
あとCOBOLとかからの伝統だろうけど、関数の前に表のようなコメントを入れるという習慣がある。これは米英では一般的なんだろうか。この本の趣旨から言うと、そういうコメントは悪手ということになる。でも書けと言われると書かないといけないんだよな。関数は思うほど役に立ったことがないんだが、ファイルの先頭に概要が書かれていると開くときに安心はするね。ファイル名が項番で付けられていたりすると、どうしても内容が他の表で見ないといけないとかあるしね。
そんな日本的な事情を汲むと全部容易にできるものではないけども、かなり参考になる例がある。それを気づける状態になるというのが重要なのではないかと思う。まず自分が読みにくいコードを書いていることを理解することが肝要。でも、どうしたら良くなるかを方向付けないと直しようがないと思うので、この本で例で理解するのは重要だと思う。
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)
- 出版社/メーカー: オライリージャパン
- 発売日: 2012/06/23
- メディア: 単行本（ソフトカバー）
ネタバレというか、内容を小出しにしていくよ。気になったら上のリンクからどうぞ。
手短に言うと、自分にも読む相手にもわかりやすいコードを書きましょう、と言う話。簡単なようでいて難しい。というのは、自分が読みにくいコードを書いていること自体を認識するところから始めないといけないから。
内容的にはプログラミングの構造とかは少し出てくるんだけど、いわゆるアーキテクチャやデザインパターンの話は出てこない。もっとプリミティブな根源的な問題というか、字面をどれだけ理解しやすいものにするかというものでした。要するに「コードを読んですぐわかる書き方をしよう」ということです。
そんなもん、個人の工夫でなんとでもなるだろ、とか、とりあえずコーディング規約に反していなければいいだろ、と言われればそうかも知れません。だけど、そこには自分を含め、後で読む人のための配慮というものが必要だろうということなんだろうなと思います。
例示として、C++、JavaScript、Python、Javaを使っているが、応用的なところがないので理解には問題ないとしているが、やっぱり知っていた方がいい。
cout << "hogehoge" << endl;
と書かれてC++が全くな人はちょっと理解しづらい（ただ文字列を出しているだけなのに）。あとC++関係で、コピーコンストラクタとか代入演算子の再定義とか書いてあるんだけど、クラスのある他の言語を知っていても理解が辛い気はする。
なので、上の言語の三つくらいは軽くは知っていないとサラッと読めない。読み飛ばしてもいいけど、十分に理解しているとは言えない。まぁ面倒でもググって調べれば済むだけの話だけど、ネットがない出先ですんなり通読するのは難しいだろう。というか、今のようにWebを少し調べれば理解できる状態になったから成立する書物だろう。そうじゃなきゃ、各言語の初歩的な文法解説本が必要になってしまうしね。
読んでいると痛いことが結構書いてあるんだよね。はじめの方にあるんだけど、tmpとかretvalは変数名として内容が分からないからあまり良くないとか、身に染みることは結構ある。だから、初心者よりもある程度のボリュームを書いた中級者におすすめなのだ。知らずにやってしまう、どうしても面倒でやってしまう悪習のオンパレード。というほどでもないんだけど、それはよくやるけど分かりづらいでしょう、ということはかなりありますね。書いている人ほどやりがちなところがあるから、身を正すにはいい経験になるとは思いますよ。
読み終わって目次をサラッと見てみると、こんな感じ。
重要じゃなくても気になったものは入れてある。
・変数関数などの名前にわかりやすい情報を盛り込む。
・変数スコープは小さい方がいい。
・名前は誤解されないものを選ぶ。
・ノーテーションとか見た目は綺麗に保つ。
・コメントすべきことを知り正確で簡潔に。
・制御フローは深く複雑にしない。
・巨大な式は分割する。
・役に立たない一時変数は削除する。
・変数のスコープは言語によって微妙に違う。
・無関係の下位問題を汎用コードにする。
・散らばった同じタスクはまとめる。
・ライブラリを使って短いコードを書く
・テストを読みやすくて保守しやすいものにする。
・設計から考えて読みやすいものにする。
箇条書きにしてしまうと、何だこんなものかと思ってしまうのだけれど、例示されたコードがわかりやすくて秀逸だ。いろいろ言語はあるのだけれど、深入りしない限りは大体何をしようとしているのかは大体はわかるし、それを前提に書いてあるので、わかりづらい例も読みづらいことを意識しやすいものになっているし、それを改善したコードもどう変わったのかがわかりやすい。
それを例示するのは結構難しいことなんじゃないかと思う。それが色々な言語に渡っているならば尚更のことである。当然のことながら、上の箇条書きよりか内容はぜんぜん理解しやすい。
翻訳本のオライリーにしては、翻訳っぽくない読みやすさである。だけど、変数の付け方とか、日本人としてはすんなり入ってくるものではなかったりする。そこは翻訳うんぬんというものではないのだけれども、英語にして日本人がわかりやすいかどうかと言うのは一つのハードルであると思う。Depreciationと書いてもすぐにわかる人いないと思うけど、ローマ字でGenkashokyakuとか書いた方が日本人には確実ですしね。正直長くて読みづらいけど、意味の通りから言うと間違いがない。
あとCOBOLとかからの伝統だろうけど、関数の前に表のようなコメントを入れるという習慣がある。これは米英では一般的なんだろうか。この本の趣旨から言うと、そういうコメントは悪手ということになる。でも書けと言われると書かないといけないんだよな。関数は思うほど役に立ったことがないんだが、ファイルの先頭に概要が書かれていると開くときに安心はするね。ファイル名が項番で付けられていたりすると、どうしても内容が他の表で見ないといけないとかあるしね。
そんな日本的な事情を汲むと全部容易にできるものではないけども、かなり参考になる例がある。それを気づける状態になるというのが重要なのではないかと思う。まず自分が読みにくいコードを書いていることを理解することが肝要。でも、どうしたら良くなるかを方向付けないと直しようがないと思うので、この本で例で理解するのは重要だと思う。
コメント 0