新刊『リーダブルコード』が6/23に発売されますが、すでに誤植がありました。 - capsctrldays(2012-06-16)
というのはさておき。
まずタイトル。
原著は「The Art of Readable Code」
The Art of ~ というタイトルの本はわりとたくさんあるし、
オライリーからも何冊か出ています。
これをどのように日本語にするのかというのは結構悩ましいと思うのですが
本書では「リーダブルコード」ときました。
オライリーの本で良く見る「アートオブ~」よりは良いと思います
(The Art of Prolog → Prolog の技芸 みたいのが良いかも知れませんが
この本で「技芸」というのはどうかという気も)
同様の内容の本でまず思い浮かぶのが「プログラム書法」なのですが、
いかんせん書かれた時期が古く、(今でも有効なものが少なくないとはいえ)
気軽にオススメできるものとは言い難いものがあります。また、訳者まえがきにもあるように
( Amazon.comには「Nothing New(別に普通じゃん)」とのレビューもある
)、
読んで目から鱗が落ちるといったものはあまり(ほとんど?)ないのではないでしょうか。
しかしだからといって価値がないということはなく、読みやすい形できちんとまとめられた
ことはとても良いことだと思います。
以下内容についてつらつらと。
原著者に対して言うべきことも混じってますが悪しからず。
p12 で PHP の explode のネーミングについて色々書かれているんですが、
確かに名前だけ見ると split との違いがわからないというのはそうでしょうね。
とはいうものの、どういう名前が良かったのよというと…
という気はするのですよね。
あー Perl の chop と chomp みたいな感じ?
2.2 tmp や retval などの汎用的な名前を避ける
ここはぜひとも 「flag」も挙げていただきたく :)
3章扉絵は、翻訳ってタイヘンだよねえと思わせるものでした :)
3.4。
first/last と begin/end の使い分けにはそんな意味が!
p35 「リンクトリスト」とあるんですが、
「リンクリスト」でないのがいい感じです。
まあちと収まりが悪いかなってのも同時にあるんですけども。
5章 コメントすべきことを知る
5.1 コメントするべきでは「ない」こと
p56 コメントするべきでは「ない」ことを知る
p69 コメントすべきでは「ない」こと
「すべき」か「するべき」か統一した方が良い気がします。
定数にコメントをつける
NUM_THRADS = 8 #値は「>= 2 * num_procssors」で十分
コメント部分の、特にカッコの中が文章として違和感があります。
原著の英語コメントだと素直に読めるんですけど
7.3 三項演算子
原著では conditional operator となっているのになんで
「三項演算子」にしたんだろうかという疑問があるのですが
それはまあおいといて
return exponent >= 0 ? mantissa * (1 << exponent) : mantissa / (1 << -exponent);
if (exponent > 0) {
return mantissa * (1 << exponent);
} else {
return mantissa / (1 << -exponent);
}
シフト量に負の数指定して良かったでしたっけ?
(追記) exponent 自体が負の数になっているので、シフト量自体は正の数になってます。
ということでコードに問題は無し。
Java演算子メモ(Hishidama's Java Operator/Expression Memo)
シフト演算子
シフト演算子は、整数型に対してのみ使える(浮動小数floatやdoubleでは使えない)。
Javaでは整数の符号の有無を型では管理しない(常に符号有りとして扱われる)。
(C言語やC++では「int」に「signed int」と「unsigned int」がある)
その違いが現れるのはビット右シフト演算なので、右シフト演算子には符号有り用の「>>」と符号無し用の「>>>」が存在する。[2003-07-06]
「>>」ではシフト前の符号が保存されるが、「>>>」では保存されず、最上位ビットに0が入る。 (2の補数表現においては最上位ビットが符号を意味する)
例えば-2(0xfffffffe)に対して「-2 >> 1」は「-1(0xffffffff)」になるが、「-2 >>> 1」は「0x7fffffff」になる。
ただしbyteやshortに対する「>>>」は注意を要する。→数値の昇格
シフト演算子の右オペランドは正の数しか扱えない。というか、負の数を指定して逆方向のシフトになったりはしない。
なぜなら、右オペランドに対し、左オペランドがintの場合は「& 0x1f」、longの場合は「& 0x3f」してから
計算されるため。intは32bit、longは64bitなので、その範囲を超えるシフトは無意味、という判断なのだろうか。
(64ビット以上シフトすれば、結果は常に0(負数の符号付き右シフトなら-1)だから)
つまり、「int a」に対する「a << -1」は、「a << (-1 & 0x1f)」なので「a << 31」と同じ。
p90 の
「do/while ループは、whileループで聞きなおせることが多い」ということで
例に出されている書き換え前後のコード、
今ひとつよろしくないのではと。
ループの条件式のどこが変わってるんだろうかとちょっと悩み、
違いを把握したところでそれはないんじゃないかなあと感じました。
p94 鍵となる考え
「変更するときにはコードを新鮮な目で見る」
「一歩下がって全体を見る」
というのは実にいいですね。
8.7 式を簡潔にするもう1つの創造的な方法
C++ で、プリプロセッサーマクロを使って「簡潔」にしているんですが
マクロなしで同じことをするには?
言語によってはいろいろと使えるものもあるでしょうけれども。
p113
9.1 変数を削除する の 中間結果を削除する にあるコード片なのですが
var remove_one = function (array, value_to_remove) {
for (var i = 0; i < array.length; i += 1) {
ここでページの終端に来て、次ページの頭に
if (array[i] === value_to_remove) {
array.splice(i, 1);
return;
}
}
};
と続くのはどうにかならなかったのかなあと。
奇数ページから偶数ページへと変わるところなので
ページをめくらないと続きが見られないのですよね。
原著は電子書籍で買ったので、原著がどういう風になっているのかは
確かめられませんでした。
9.5
「去るものは日々に疎し」(いい意味で)
の原文との対比
p130 「無関係の下位問題」
第11章
p144
図
12.2 ライブラリを知る
の小題の原文との対比
12.3
の書き換え作業
p165
脚注
p169 に 「でも、アクセスが必ず同時に行われていることに気づいたので、」
というくだりがあるんですけど、
その前後を読んでみてもこの「同時」ってどういうことかがよくわからなかったので
原著の同じ部分をみてみると
However, we noticed that the repeated accesses were always in a row.
となっているんですよね。
キャッシングしようとしたアクセスの履歴が
read Object A
read Object A
read Object A
read Object B
read Object B
read Object C
read Object D
read Object D
だというのを考えると、同じ行 (row) を複数回繰り返しアクセスして
次の行へ移っているので単純なキャッシングでも効果が結構あったということですよね。
「同時」はちょっと違うんじゃないかなあ。
この辺で力尽きたw
13.3
コードを小さく保つ
YAGNI でも・・・?
ライブラリの再利用はなぜいいことなのか
「出荷用」→ shippable
UNIXツールの活用
14章、15章
高品質のコードを書くための書籍
要書き足し