スキップしてメイン コンテンツに移動

投稿

12月, 2014の投稿を表示しています

”この本もう要らないって言いたい”と読みました

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice) 著者 : Dustin Boswell オライリージャパン 発売日 : 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) ○プログラムのことを簡単な言葉で説明する技法について説明した。  説明するこ

”知らないということを知れるかもしれない”と読みました

プログラマが知るべき97のこと 著者 : オライリージャパン 発売日 : 2010-12-18 ブクログでレビューを見る» 耳が痛くなる言葉も、 そうでない言葉もがたくさんありました。 あらためて、当たり前のことを当たり前にやるのは、 本当に難しいことだと感じました。 もっと覚えなくてならないこと、 もっと学ばなくてはならないこと、 もっと経験しなくてはならないことが、 たくさんあると思いました。 できてないと感じたのならやれば良くて、 できてないと感じれたことが、 今の自分の一歩目なのだと思いました。 ざ きのこ本。 (以下抜粋。○:完全抜粋、●:簡略抜粋) ○壊れていないものを直すのは無意味です。(P.13) ○たとえコードが4行ほどのもので、  行っていることが同じだったとしても、  それはたまたま一時的にそうなっていただけのことです。(P.14) ○コードレビューを成功させるためにもっとも有効な方法は、  レビューを楽しいものにすることです。(P.29) ○関数はできる限り短くし、機能は1つに絞り込む。  古くから言われる「24行制限」は今も有効である。(P.31) ○英語には、  たとえば「Make up your room, be quiet and do your homework」ということを  一語で伝えれるような単語はないのです。(P.39) ●デザインパターンの多くは明らかにアプリケーションの中の重複を減らす、  あるいは排除することを目的としています。  オブジェクトの使用する条件がいつも同じであれば、  Abstarct Factory、Factory Methodパターンを、  オブジェクトのふるまいに種類があるのであれば、Stategyパターンを使用します。(P.59) ●金融関係のアプリケーションには浮動小数点数を使うべきではない ということも書いておくべきでしょう。  (中略)  浮動小数点数は、元々、科学技術計算を効率的に行うことを目的としたものです。 ●YANGI(You Ain't Gonna Need It:それはたぶん必要ない)  余計かもしれないがおもしそうだと思えた。  将来必要になるかもしれないと思った。  必要かどうか判断に迷った。  常に考える必要があるのです。 い