 |
オライリージャパン
発売日 : 2012-06-23
|
そういう風にしたいよねって思うんだけど、できないことだらけ。
そんなところをがつがつと突かれる。
うんうん、ふんふんって読めて気持ちいい。
これからはもっといいコードを書こうと思うし、
書けるような気がしてくるが、
いざ書いてみるとそれは幻想でしかない。
本読むだけじゃなくて、コード読まないとね。
そんなことも教えてくれて、
また読みたくなるリーダブルブックです。
（以下抜粋。○：完全抜粋、●：簡略抜粋）
○名前に情報を詰め込む（P.26）
●範囲指定はfirst/last、min/max、
包含・排他的範囲にはbegin/endを使う（P.33）
○これはあまり知られていないことである。
つまり、ここにコメントをつけるべきなのだ。（P.64）
●「コメントにはWHATではなく（あるいはHOWではなく）WHYを書こう」というアドバイスがある。
僕からのアドバイスはこうだ。
「コードを理解するのに役に立つものなら何でもいいから書こう」（P.68）
○基本的にはif/elseを使おう。三項演算子はそれによって簡素になるときだけ使おう。（P.89）
○これでネストの深さが2レベルから1レベルになった。
もっと大切なのは、精神的なスタックから「ホップ」する必要がなくなったことだ。
すべてのifブロックはreturnで終わっている。（P.95）
○このコードが言いたいのは「ユーザは文書を所持しているか？」だ。
要約変数を追加すれば、この概念をもっと明確にできる。（P.101）
○幸いなことに同じ式がいくつかあるので、
それらを要約変数として関数の最上部に抽出すればいい（これはDRY原の実例でもある）。（P.106）
○アクセスはできるだけ制限して、
変数のことが「見えてしまう」コードを減らすのがいいとされている。（P.115）
○プログラムのことを簡単な言葉で説明する技法について説明した。
説明することでコードがより自然になっていく。（P.165）
○たまには標準ライブラリのすべての関数・モジュール・型の名前を15分かけて読んでみよう。（P.172）
○平均的なソフトウェアエンジニアが1日に書く出荷用のコードは、10行なのだそうだ。（P.173）
○コーディングするよりもUnixツールボックスを使う（P.173）
○冒険。興奮。ジェダイはそんなものは求めておらん。（P.175）
そんなところをがつがつと突かれる。
うんうん、ふんふんって読めて気持ちいい。
これからはもっといいコードを書こうと思うし、
書けるような気がしてくるが、
いざ書いてみるとそれは幻想でしかない。
本読むだけじゃなくて、コード読まないとね。
そんなことも教えてくれて、
また読みたくなるリーダブルブックです。
（以下抜粋。○：完全抜粋、●：簡略抜粋）
○名前に情報を詰め込む（P.26）
●範囲指定はfirst/last、min/max、
包含・排他的範囲にはbegin/endを使う（P.33）
○これはあまり知られていないことである。
つまり、ここにコメントをつけるべきなのだ。（P.64）
●「コメントにはWHATではなく（あるいはHOWではなく）WHYを書こう」というアドバイスがある。
僕からのアドバイスはこうだ。
「コードを理解するのに役に立つものなら何でもいいから書こう」（P.68）
○基本的にはif/elseを使おう。三項演算子はそれによって簡素になるときだけ使おう。（P.89）
○これでネストの深さが2レベルから1レベルになった。
もっと大切なのは、精神的なスタックから「ホップ」する必要がなくなったことだ。
すべてのifブロックはreturnで終わっている。（P.95）
○このコードが言いたいのは「ユーザは文書を所持しているか？」だ。
要約変数を追加すれば、この概念をもっと明確にできる。（P.101）
○幸いなことに同じ式がいくつかあるので、
それらを要約変数として関数の最上部に抽出すればいい（これはDRY原の実例でもある）。（P.106）
○アクセスはできるだけ制限して、
変数のことが「見えてしまう」コードを減らすのがいいとされている。（P.115）
○プログラムのことを簡単な言葉で説明する技法について説明した。
説明することでコードがより自然になっていく。（P.165）
○たまには標準ライブラリのすべての関数・モジュール・型の名前を15分かけて読んでみよう。（P.172）
○平均的なソフトウェアエンジニアが1日に書く出荷用のコードは、10行なのだそうだ。（P.173）
○コーディングするよりもUnixツールボックスを使う（P.173）
○冒険。興奮。ジェダイはそんなものは求めておらん。（P.175）
コメント
コメントを投稿