![リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice) リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)](http://ecx.images-amazon.com/images/I/51MgH8Jmr3L._SL160_.jpg)
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)
- 作者: Dustin Boswell,Trevor Foucher,須藤功平,角征典
- 出版社/メーカー: オライリージャパン
- 発売日: 2012/06/23
- メディア: 単行本(ソフトカバー)
- 購入: 68人 クリック: 1,802回
- この商品を含むブログ (111件) を見る
素晴らしい本だった!!
印象に残ったところを中心にまとめておく。
名前大事。超大事。
大事なことなので二回言いました。
抽象的な名前よりも具体的な名前を使う
下のコードでは誤解が生じる。
引数の単位は何だろう?
秒?ミリ秒?
実装を読めばわかるだろうけど、そうしなくてもいいようにすべきだ。
単位が明らかになった。
どれくらいの抽象度で書くべきかは都度判断するしかない。
誤解されない名前
下のコードでは2通りの解釈が生まれてしまう。
- 問題があった場合に true が返る
- 問題がなかった場合に true が返る
これはよくない。
曖昧さを残さない名前をつける必要がある。
これならば解釈の違いは生まれない。
テストコードに状況を書く
こういうテストは書くべきではない。
テストコードはプロダクト自体のコードと比べて雑に扱いがち。
さほど複雑でないメソッドのテストならなおさら。
上のコードのように一つのメソッドに詰め込んでしまうこともある。
でも大抵の場合、複雑さは後々増していく。
後でテストコードを追うのは至難のワザ。
なので初めからテストコードが想定する状況を名前に書くようにするのがベター。
自分以外の誰かがメンテナンスする場合にこの基準に合わせてコードを書いてくれることも期待できる。
最後に
気軽に読める分量で、この本自体がリーダブル。
Kindle 版がないのが唯一の不満。
プログラマーならば必読といっていい。
デブサミの技術書大賞にあがったのもうなずけた。
![リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice) リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)](http://ecx.images-amazon.com/images/I/51MgH8Jmr3L._SL160_.jpg)
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)
- 作者: Dustin Boswell,Trevor Foucher,須藤功平,角征典
- 出版社/メーカー: オライリージャパン
- 発売日: 2012/06/23
- メディア: 単行本(ソフトカバー)
- 購入: 68人 クリック: 1,802回
- この商品を含むブログ (111件) を見る