概要
- リーダブルコードを読んだ
- 相当前に買っておいて、積読していた
- 仕事でコードを書く機会があり、可読性のあるコードの重要さを知ったので読んだ
- 基本的に書いたコードは他人から見られる時間のほうが長い
- 今まで競技プログラムとか個人用のプログラムしか作ったことがなかったので、あんまり人に読まれることを意識したことがなかった
- しかし、現在の仕事についてからは、他人に読まれる機会が増え、これはまずいと感じた
- 可読性が高いコードを書くためのルール・考え方が書いてある
- 命名規則、コメントの付け方
- 現在の仕事に付く前は、自分だけのプログラムしか作成してなかったので、この辺りの考え方が身についていなかった
- 誤解がないように何をするための変数なのか、具体名をつけるなど……
- ここらへんは別の方々の記事で散々言われていることだ
- 何でもかんでもコメントつければ良い訳では無い
- ここはつけないと分からないよね、というところにつける
- 短く、だけど分かるように
- ネストを浅くする
- 関数から早く返す
- ガード節を使ってさっさと返す
- コードは一つずつタスクを行う
- 複数のタスクを行わないようにする
- 結構やってしまいがち
- 短いコードを書く
- 一番見やすいコードは、「何も書かれてない」コード
- 笑っちゃうが、一番しっくり来た言葉
- 小さくすることが大事
- かといってショートコードのように暗号みたいなの書け、というわけではない
- ライブラリとか使えるものは使っておけということ
- 一度使えばすぐに書けなくても「そういえばあれあったな」ってなり、何度も使っているうちに、そのうちスラスラ書けるようになるとのこと
- テストコードも同様に短くコンパクトに
- バグの発見・修正しやすいエラーメッセージも重要
- 命名規則、コメントの付け方
感想
- 命名規則とかは必ずしもこれに従う必要ないものの、考え方は共通するものがある
- 大文字・小文字で表現するだけでクラス名、ローカル変数と伝えられる
- 表記だけで何を表しているか、を誰でも分かるようにすることが重要
- 一度に一つのタスクだけを行うようにする、という点が個人的に学びがあった
- 長くなる場合は、切り出して別の関数として作成する
- 何かのタスクを作るときは、作る前に全体像をイメージし、AとBとCが必要、というように細分化して小さなまとまりを作っておくことが大事だと感じた
- 如何にして短く適切な情報量を入れるかを意識することが大事なのではないか、というのがこの本を読んだときの印象であった
- 小さなコードでも書くときは常に意識しながら行っていきたい
- 現状の仕事だと、コードを書くことが中々ないが……
- 今度はGood Code, Bad Code を読みたい
