リーダブルコード の商品レビュー

ダスティンボズウェル,トレバーフォシェ【著】,角征典【訳】

2014/02/28

保守性を高めるために読みやすいコードを書くことが大事。
そのための実践的なレベルに落とし込んだ本。

印象に残ったとこ
・ダイオウイカは非常に知的な生物だが欠点がある。
　ドーナツ状の脳が食道を取り囲んでいるため、大量の食道を一度に摂取すると脳に損傷をうけてしまう

2014/02/15

才知の発露である芸術的な一文よりも、誰が見ても分かるような複文にすべきだ。いまの自分に、他人や将来の自分は付き合いきれないかもしれない。将来の自分とは6か月後の自分だ。

こんなこと仕事を始めて少し経てば分かることだ、方針自体は。より具体的に合理的に整理したのが本書。

アメリカらしい。オライリーだし。挿絵とか文章の運び方やセンスが。もろに英文を和訳しましたって感じ。このノリ嫌いじゃないので楽しんで読めた。

あと、巻末に索引があるだけで高評価。

有能でありかつ商品化されることを嫌うプログラマーは、このようなリーダブルコードを期待することは難しい。集団とそこに所属する個人の利害関係を思う。そこをうまく利害の方向性を同一にできるかが経営の技量とことかいう。

そういう意味では経営者がコンサルタント雇って自分では言えないことを代わりに言わせるみたいな、そんな匂いも感じる一冊。

p10."「空虚な」単語は避けるべきだ。例えば、「get」はあまり明確な単語ではない。「get」という単語からは何も伝わってこない。"

日本語でもよくある。いちばん気になるのは「登録」だな。

p12."tmp、retval、fooのような名前をつけるのは、「名前のことなんて考えていません」と言っているようなものだ。"

p20.変数名に値の単位を含める。重要な属性を追加する。ハンガリアン記法ほど厳格でなくてよい。

p30.”名前が「他の意味と間違えられることはないだろうか？」と何度も自問自答する。”

p43.”見た目が美しいコードのほうが使いやすいには明らかだ。考えてみれば、プログラミングの時間のほとんどはコードを読む時間なのだッ！”

p44.改行や空白を入れて読みやすくする。修正の際もそれほどの手間ではない。さらにブロックや段落を入れる。

p59."コメントはひどい名前の埋め合わせに使うものではない。"

p60.コメントには自分の考えを記録する。

p61."コードの欠陥を文書化することを恥ずかしがってはいけない。"

p72."古典漫才の「Who's on First?」からもわかるように、代名詞は物事を複雑にしてしまう"

日本語だと主語も不要になるからこんな状況への遭遇機会が増す。

p91.do/whileを避ける。

p93."基本的にはgotoは使わない"

p93.ネストは浅く、早めに返す。

p126.変数をなるべく軽くする。減らす、スコープを小さくする、書き込みを一度だけにする。

p130."エンジニアリングとは、大きな問題を小さな問題に分割して、それぞれの解決策を組み立てることに他ならない。"

p141.プロジェクト固有のコードから汎用コードを分離する。"ほとんどのコードは汎用化できる。"

p155."「一度に1つのタスクを行う」"

p165.プログラムを簡単な言葉で説明する。"説明することでコードがより自然になっていく。"

p172."たまには標準ライブラリのすべての関数・モジュール・型の名前を15分かけて読んでみよう。"

p175."できるだけコードを書かない"

p202."外部の視点を得る" "「他の人」には、6か月後の自分も含まれている。"

2014/01/23

綺麗なコード、或いは読みやすいコードの具体的な意味が分からなかったから、この本はとても参考になる。
変数の付け方とかに意識すべきポイントとかが分かって良かったけど、実践するにはもう少し英語力あげないと無理な気がした。

2014/01/10

先輩の勧めで読みはじめる。

もうちょっとコーディング能力が上がってからの方がしっくりくる気がする。
でも美しいコードの全体は掴めたような。
1年後にもう1度読みたい。

2014/01/01

理解しやすいコードを書くための方法が、具体的なコード例などを用いて紹介されている本。最後の章では、それまでに本書内で紹介してきた様々な方法を用いた課題例があり、内容の復習になると同時に、実践する時のイメージを持てるような構成となっている。

2013/12/22

コードを書く人全ての人に読んでおいて欲しい。特にコードの（きれいな）書き方がわからないような新人さんには特に読んで欲しい。

2013/12/08

コードの見た目の修正や変数名の付け方のことから始まって、実コードを例とした設計の講義まで及ぶ。一読では身に付かないが、大部ではないので傍らに置いて時々読み返しつつ、コードの質を改善していきたい。

2013/11/23

【認識】
読みやすいコードを書くために気をつけるべき点を説明する本

【対象】
・きれいなコードをかけなくて悩んでいる人
・コードでご飯食べている人

【感想】
読みやすいコードの書き方をうまく体系化できていると思う。
命名から始まって、コメントの書き方、制御構造に関して、設計に関してというように、だんだん上流工程に近づく感じの構成。
どこから読んでも大丈夫なようになっている。
この構成と併せて、例題も多く、ダメなコードと良いコードが非常に分かりやすい。

コメントに関するところが勉強になった。
有用なコメントとはその時考えたことを残すもの、としていた。
その通りなんだけどよく忘れる。
関数の名前や読めばすぐ分かること、をそのままコメントにしてしまうことがあるので気をつけよう。

ブール値の意味を名前に込めることは面倒でやらないことが多いけれど、リファクタリングの工程でそれは行ったほうがよさげ、というかするべき。

以前さらっと読んだ別の本は微妙な感じだった。
これはそういうことが無かった。
というのも、適切にコメントをつけましょうとか、意味のある変数名をつけましょうとか、そういう抽象的なことが書いていない。
どういうコメントがダメで、どういう変数がダメか、ちゃんと"理由"を示した上で、じゃあこうしましょうよと一般的化がなされていた。

すでにしていることは多くあった。
そうしたほうが良いということもけっこう知っていた。
しかし、面倒でやっていないことが多い。
それをさとされた感じだった。
この本を読んですぐできることは多くあるので、実行していきたいと思う。

2013/11/01

DeNAの新人研修にて最も評価が高かった書籍ということで手にとった。①わかりやすい名前②正確なコメント③コードに思いを込めるなどわかっているようで中々実践できていないテクニックが記載してあり、勉強になった。コードのみで他者に意図を伝えることができるよう、今後書くコードは全て読みやすいコードになるよう努めたい。

2013/09/11

とりあえずコード書けるようになったけど、もっとうまく書きたいって人向け。後輩に読ませたい。自分にとっては、経験の中でこういう考えを身につけてきたんだなあ、と感慨に浸る前半と、読むのが面倒になった（普通に難しい）後半だった。