Dustin Boswellほか「リーダブルコード」オライリージャパン

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

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

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

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

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

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か月後の自分も含まれている。”