読者です 読者をやめる 読者になる 読者になる

エンターテイメント!!

遊戯王好きのJavaエンジニアのブログ。バーニングソウルを会得する特訓中。

【書評】リーダブルコード

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

きっかけ

そもそも読んだのは、2014年の終わり。
ものすごい売れているので、パラパラめくったら、かなり共感できることが書かれていたので、買った。
すでに買っているのに、読了してないがために2冊買ってしまった思い出の品。
それをきっかけに、クラウドで買った本を管理するようになった。

感想・内容

読んだ感想とまとめ。
主観が入っているので、興味を持った方は購入したほうがいい。
()は、いつも通り、本にはない心の声。

コードの大原則

コードは理解しやすくしなければならない!

なぜなら、読みやすいコードは、他人が最短で理解できるコードの事だから。
他人が理解しやすいようにコーディングすることが、凡人と達人の分かれ目。

コードは短いほうがいいが、他人が理解するまで時間を短くするコードを書くことが優先。
(Javaだと三項演算子がそう。確かに使うとコードが短くなるけど、使い時を間違えると意味が分からなくなる。)

理解しやすい設計が、優れた設計。
(難しいロジックを難しいまま設計するのは、よい設計者とは言えない。)
(エンジニアの腕の見せ所は、分かり難い事をいかに分かりやすく設計するか。その一点に尽きる。)
(難しいものを難しく設計してドヤ顔するのは、恥をしらない愚か者。)

命名

名前に情報を詰め込む

明確な名前を付けることは、多くの情報を詰め込めること。
いい名前は目的や実態を表す。
名前は、短いコメントととらえるべき。

名前の長さ

スコープの範囲で決める。
スコープが狭ければ、処理が見えるため、変数名は短くていい。
(for分のインデックスに "i" を使っていいのは、スコープが狭い時だけって意味だね)

長い名前が問題ではない。意味不明な名前が問題なのだ!
(意味不明な名前とは、ようするにマジックナンバーを使ったりするやつ。)
(日本は、なぜコード値のようなものを命名したがるのだろうか?もの凄く疑問)
(大手SIは、よくすることに思える。)

誤解

誤解されにくい命名を心がける。
命名する際は、誤解を生む要因がないか、積極的に探すクセをつける。
(誤解を生むような命名にするとバグの温床になる。昼ドラで誤解を生むような会話をすると、泥沼に落ちるのと一緒)

コードの美しさ

コードの美しさは、読みやすさ。
シンプルさこそを絶対の基準にする。
美しい = いい設計ではないので、注意。

美しさの原則

  • 統一されたレイアウト
  • 似ているところは似せる
  • 関係するコードをブロック化

コードの段落表記

  • 考えをグループ化できる
  • 他との考えの違いを区別しやすくする
  • 視覚的な踏み石
    (枕詞って言った方が日本人にはしっくりくるかな?)
    (例を出すと、熱湯風呂に入るのをためらっている奴が、「押すなよ」って言ってたら、押してあげることだ)

一貫性あるスタイル > 正しいスタイル
正しさよりも一貫性が重要。
見た目をそろえることが、バグの早期発見につながる。

コメント

コメントすべきこと

書き手の意図を読み手に伝える。
コメントが名前の説明になる場合、それは名前がおかしいので、考え直す。

コメントは、修正を促したり、なぜそうなったのか背景を載せるように心がける。

一般的なコメント例

TODO:あとでやるタスクを書く
FIXME:既知のバグや不具合
HACK:許容しにくい解決策
XXX:危険、問題あり

定数のコメント

なぜその値なのかを考える必要がなくすコメントにする。

コメントを書く基準

読み手が、プロジェクトを熟知していない人と考える。
つまり、コメントに書かなければいけないこととは、質問されそうなことに対する答えだ。

コメントを書く作業フロー

  1. 頭にあるコメントをすべて書き出す
  2. 不要な個所を探す
  3. 改善、添削

コメントすべきではないこと

コードからすぐに抽出できること。
コードを補うコメント→コメントを書くのではなく、コードを修正すべき。

コメントに書くべきこと(推奨すべきこと)

  • なぜこの作りになっているか
  • コードの結果レベル(TODO, FIXMEなど)
  • 定数の背景

読み手が欲しているもの

  • 疑問に思うことを先回りして書いておく
  • ファイル・クラスの全体像
  • 一般的ではない動作

コメントの簡素化

コメント領域は少なくすべき。
多いコメント→それだけコードに問題がある。

歯切れのいい文書、短いけど的確な文章が、読みやすさにつながる。
特に、あいまいな代名詞は除去する。
「それ」「これ」は、読み手が何を指しているのか紐解く必要があり、手間と誤解を招く。
使ってもいいが、何を指しているのか明確にしてあげる。

ロジック

if文

条件は、否定形よりも肯定系を使う。
否定形は、分かり難さにつながる。
条件の優劣も見やすさにつながるので、注意。

三甲演算子

基本的には使うべきではないが、よりコードが簡潔になる場合は使うべき。
(これをどう使うかで、コーディング能力がわかる。)

ネスト

  • 深い=精神的苦痛を当たる
  • 浅い=理解しやすい

ネストを浅くするには、処理を途中で終わらせるようにロジックを組む必要がある。

難しいロジック

最善手ではない可能性が高い。
逆転の発想が必要になる。
巨大で難解なロジックはなるべく分割する。

変数

一度だけ初期化するもの。
変数の変更が多くなるということは、処理を追う必要があり、面倒。

テスト

テストコード

テストコードが読みやすい=テスト以外も読みやすい。

テストコードが読みにくいと起こること

  • 本物のコードの修正を恐れる
  • 新しいコードを書いてもテストケース書かない

テストの原則

大切ではない詳細 → 隠す 大切な詳細 → 目立たせる

(つまり、本質ではないことは、処理を隠蔽してやる必要がある。)

テストデータ

なるべく単純化させる。
複雑なテストデータは、隠すか単純化しないと、テスト恐怖症を引き起こす。

テストやりすぎ問題

90%のテストは楽だが、残りの10%は難しいもの。
実際に100%のカバレッジを達成しても、バグがゼロになることはない。
コストとバグの消化が割りに合わなくなるので、許容店を考える。

最後に

コードの質を高める

簡単なのは、外部の視点を得ること。
外部には、6ヶ月後の自分も含まれる。
(ぼっちにやさしい!)
(自分は、触らなくなって3日立つと忘れるので、うまく利用する)

エンジニアで大切なこと

実践すること

気づく機会は、手を動かしたもののみに与えられる。
気づきがなければ、成長はできない。

他人に頼る

外部の視点は、自分に気づけないことに対する気づきを与えてくれる。
なので、指摘してくれる人は大切にすべき。

(GitHubにコードを晒す連中は、コレが主要な目的だと思う。)

感想

いろいろ考えが変わった一冊。
自分ではなく、読む人にたいしてコーディングするという考えが、一番印象にのこった&ためになった。
意外にも、それが出来てない奴が、日本には多い。
言われたことをそのまま実装するだけでは、ダメだということを痛感できた一冊。
新人教育で読ませるだけでも価値があると思うんだが、ウチの会社は理解せんだろうな。。。

これを読書会を社内で開くことを検討中。
やって結果が出たら、ブログに書きたい。