リーダブルコードを3回読んで覚えた事まとめ

リーダブルコードを3回読んだのですが、覚えた事などまとめておきたいと思います。

これまで色んな現場に行き、コードが読みづらい事も多々ありました。

メンターな先輩がこの本を教えてくれて、コードがもっとわかりやすければ、チームでの開発効率もあがり、技術的な差異によるコードの違いも許容出来る範囲に収束していく。という方針で読み始めました。

正直、今までコードはコメントに記載があれば、わかりやすくなるものだと思っていました。コメントがないからわかりづらい。だからコメントをもっと増やそうという考えでした。(もちろんコメントはないと困る)

そういう考えだったから、自分のコードもまたわかりづらいものだったのだと反省しました。反省した事からこそ、この本が頼りに出来る基準になってきたのだと思います。

これまでオライリー(O’Reilly)の本は難しいのであまり読んだ事がなく、学生の時に授業で読んだ程度でした。そもそも自分はあまり本を読む習慣がありません。カラフルで図解が多いものでないと頭に入りづらい人間です。

でもそういった経緯があり、この本は「読みたい」というより「読まなきゃ」という前提があったので、なんとか読み進められました。読んでみると、中にはわからない例もありましたが、章の前後で関連していない事が多く、独立して読めるので、わからない例は単純に「すっ飛ばし」という感覚で読めました。

理解度を深めるため、今3回目に入ろうとしています。結構忘れていた事も多く、TIPSとして覚えた事を書いていきたいと思います。(⇒追記:3回済)

結論として先に書きますが、自分が一番大事だと思ったのは、名前付けでした。これが上手く共有出来るものになっていれば、名前そのものがコメントになり、処理概要が把握出来るからです。

最近ではこの本の影響もあり、リファクタリングを積極的に行うようになりました。今までは触らぬ神に祟りなし。という感じだったのですが、触りまくってます。この文化が自分の中で芽生えただけでも読んだ価値ありでした。

スポンサーリンク

名前

単位があるものは単位を入れる

属性や状態があるものは属性や状態を入れる

どちらでも取れる意味の名前は使わない

範囲指定の場合の注意

xからyまでという判定の時、統合を入れるかで4パターン考えられる。これの勘違いを防ぎたい。

  • x < n < y
  • x <= n < y
  • x < n <= y
  • x <= n <= y

bool値の場合の注意

フラグの意味合いや、フラグがONの時にそうなのかOFFの時なのかわかりづらい事があります。

結構need, is, hasは使い始めると便利でした。

抜けられる処理は先に書いて全部読ませない

※コードは長くなっちゃいましたがもっと複雑な場合、早く返す(return)のを意識しておくと、エラーなど例外の場合は全部読まなくて良いとわかるので楽になりました。また、最後の処理の部分が見やすくなります。

毎回毎回 !is_error を if 文に入れるのはやりません。

リファクタリング

最近ではこの本の影響もあり、リファクタリングを積極的に行うようになりました。今までは触らぬ神に祟りなし。という感じだったのですが、触りまくってます。この文化が自分の中で芽生えただけでも読んだ価値ありでした。

と、冒頭にも書きましたが、この本を読んでからとにかくリファクタリングをするようになりました。リファクタリングは本当に大事だし楽しい!!

簡単に書ける事しか上に書いていないので、また追記するかもです。