3
2

More than 3 years have passed since last update.

『リーダブルコード』を読んで心に刺さったことをまとめてみた

Posted at

はじめに

エンジニア歴2年目のエンジニアです。
かの名著『リーダブルコード』を読んで、備忘録もかねて心に刺さったことを章毎にまとめました。

1.理解しやすいコード

・コードは他の人が最短で理解できるように書かなくてはならない

2.名前に情報を詰め込む

・getやfetch,allowやdisallow,letなど、よりコードの意味が明確になる変数名を心がける
・変数名でコードの内容が推測できるのが望ましい
・具体的な名前を用いて、コードの機能を詳細に説明する

3.誤解されない名前

・名前が他の意味と間違えられないか何度も自問自答する
・最善の名前は誤解されない名前

4.美しさ

・改行等を揃える。
・関数が長い場合、意味ごとのブロックに分ける
・コードを段落に分割する。長いコードは誰も読む気になれない。

5.コメントすべき事を知る

・自分の考えを記録する
・「監督のコメンタリー」を入れる
・読み手の立場になって考える、質問されそうなことを想像する

6.コメントは正確で完結に

・コメントは高レベルで記述する。(例;「int,desc」といったコメントより「価格の高い順」と行ったコメントの方が望ましい)
・「それ」や「これ」などの代名詞を用いるのは避ける
・コメントは簡潔に保つ

7.制御フローを読みやすくする

・if/else文の順序を適切に保つ。基本原則は、[肯定系、単純、目立つもの]を先に書く
・三項演算子、do/whileは読みにくくなることが多いので、あまり使わない。代替方法が必ずあるのでそちらを使う方が望ましい方が多い
・ネストはなるべく浅くする。関数を早めに返すようにするとネストを削除できる

8.巨大な式を分割する

・式を簡単に分割するには、式を表す変数を使う。これを説明変数という。
・管理や把握を簡単にする変数のことを要約変数という。

9.変数と読みやすさ

・変数のスコープはできるだけ小さくする
・一度だけ書き込む変数を使う

10.無関係の下位問題を抽出する

・エンジニアリングとは大きな問題を小さな問題に分割して、それぞれの解決策を組み立てることに他ならない
・プロジェクト固有のコードから、汎用コードを分離する
・関数は小さく独立していれば、機能追加、読みやすさの向上・汎用性の向上・エッジケースの処理がしやすくなる
・ただし分割のやりすぎには注意。コードの可読性が下がる。
//エッジケース:極端な動作で発生する問題

11.1度に一つのことを

・長く読みにくいコードはタスクを把握し、関数(クラス)に分割してみる。
・読みにくいコードがあれば、機能を全て列挙する。
・別の関数やクラスに分割できないか考える

12.コードに思いを込める

・簡単な言葉で書く。プレゼンとコードは同じ
・実際に声に出して、コードを説明してみる。デバックの際これだけで問題が解決することもある

13.コードを短く

・コードを追加する以上に、削除してコードを軽くすることも大事
・標準ライブラリを利用し、実装の時間を短縮する

14.テストを読みやすくする

・確認したいポイントを簡単な言葉にしてみる。
・テストが失敗した際のエラーメッセージは、バグの発見や修正がしやすいものを心がける
・テストの関数に説明的な名前をつけて、何をテストしているのか明らかにする

最後に

折に触れて読み返し自身の業務に役立てていきたいと思います。
プログラマとして当たり前のことが書かれていますが、こうした当たり前のことこそ大切にしていきたいです。

3
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
2