背景
ソフトウェアエンジニア歴10年程度にして初めて「リーダブルコード」を
読んだら一言一言が心に刺さりまくったので、それらをメモしておく。
目次
- 背景
- 目次
- メモ
- いい名前をつける
- 適切なコメントを書く
- 意味のある単位で分割する
- キレイに整形する
- 基本的なことを着実にやる
- コードは理解しやすくなければならない
- コードを短くするより、理解するまでにかかる時間を短くする方が大切
- ブール値の名前は肯定形にした方が読みやすくて、短くて済む
- 最善の名前とは誤解されない名前である
- コードからすぐにわかることをコメントに書かない
- 優れたコメントは「考えを記録する」ためのものである
- 新しいチームメンバーにとって一番難しいのは全体像の理解である
- 曖昧な代名詞を避ける
- 慎重に選んだ入出力の実例をコメントに書くことは、千の言葉を書くに等しい
- 条件式の引数は、左側を調査対象、右側を比較対象にする
- 「頭がいい」コードに気を付ける。あとで他の人が読むときに分かりにくくなる。
- 変数の定義は変数を使う直前に移動する
- 一度に複数のことをするコードは理解しにくい
- テストコードとは、「本物のコードの動作と使い方を示した非公式な文書」である
- テストには最もキレイで単純な値を選ぶ
- テストしやすいコードには明確なインターフェースがある
- getは多くの人にとって軽量アクセサを意味する。実装が軽量でないならgetを使わない方がいい
- まずは新しく書くコードが読みやすいコードだけになるようにする。既存のコードを直すことはそれまで我慢する
- まずは自分が仲間のコードを読もう。そうすれば仲間も自分のコードを読んでくれるようになる
- 忘れても見たらすぐに思い出せるコードを書く
メモ
いい名前をつける
基本だけどとても重要。
変数名や関数名を考えるのに、自分はしょっちゅう英語辞書を引いてる。
適切なコメントを書く
ただコメントを書けばいいという訳じゃないということ。
どこにどんな内容のコメントを書けば読み手が理解しやすくなるか。
意味のある単位で分割する
とりあえず出来るだけ小さく分割しようとするけど、
あとになって、「やりすぎたな」って思うこともある。
分割する必要があるのかも同時に考えるようにしていきたい。
キレイに整形する
時間に余裕がないとこういうのは後回しにしがち。
未来の読み手を助けるつもりで最初から意識するべき。
基本的なことを着実にやる
これが全てだと思う。
これが冒頭でいきなり書かれていたことでぐっと心を掴まれた。
コードは理解しやすくなければならない
理解しやすいとはどういうことなのかを常に自問自答したくなる。
コードを短くするより、理解するまでにかかる時間を短くする方が大切
コードはとにかく短く書こうとしていた。
その方が読みやすいに決まっているだろうと。
でも1行あたりのコードが長くなって、それはそれで読みにくくなる。
ブール値の名前は肯定形にした方が読みやすくて、短くて済む
これは意識したことなかった。
肯定形だったり否定形だったり、その場のノリで決めてしまっていた。
最善の名前とは誤解されない名前である
なるほど、と思ったけど難しい。
複数の意味を持つようなワードは選ばないようにすればいいのかな。
コードからすぐにわかることをコメントに書かない
コメントを書くことに囚われるとやってしまいがちなこと。
同じコードを2回書いてしまっているような気分になる。
変数名や関数名がしっかりしていれば、それを見てもらえばいい。
優れたコメントは「考えを記録する」ためのものである
そのコードを書いていた時に、特別意識したことや悩んだことなどを書いておく。
分かっていても、振り返ってみると意外と書いてないことに気づく。
新しいチームメンバーにとって一番難しいのは全体像の理解である
これはコードだけでなく組織に対しても言えること。
チーム加入直後の1年間が勝負のように感じる。
曖昧な代名詞を避ける
曖昧なワードだといろんな意味に取られて、誤解を生みやすいということか。
慎重に選んだ入出力の実例をコメントに書くことは、千の言葉を書くに等しい
コードの実例って全然コメントで書いたことなかった。
どう使うことを想定しているのかがコメントに書かれていると確かに親切。
条件式の引数は、左側を調査対象、右側を比較対象にする
コードをキレイに整形する、一貫性を持たせる取り組みの一つ。
「頭がいい」コードに気を付ける。あとで他の人が読むときに分かりにくくなる。
ついつい、テクニカルな実装をしてかっこつけようとしがちなので気を付けたい。
変数の定義は変数を使う直前に移動する
冒頭に変数の宣言をまとめて書くコードが大多数なので、
これは固定観念に囚われない良いやり方。
一度に複数のことをするコードは理解しにくい
同感だけど、まず自分がそういうコードを書きがちなのでなんとかしたい。
テストコードとは、「本物のコードの動作と使い方を示した非公式な文書」である
テストがありゃいい、という訳じゃないんだな。
これを意識して、理解しやすいテストにしないといけない。
テストには最もキレイで単純な値を選ぶ
これは今まで意識していなかった。
テストがシンプルになって理解しやすくなりそう。
テストしやすいコードには明確なインターフェースがある
最近よく感じていること。
テストしやすくすることを見越して、インターフェースを設計しないといけない。
getは多くの人にとって軽量アクセサを意味する。実装が軽量でないならgetを使わない方がいい
まったく考えたことなかった。
getってつけときながら、その関数内ではいろんな処理をさせていることがある。
まずは新しく書くコードが読みやすいコードだけになるようにする。既存のコードを直すことはそれまで我慢する
既存コードまで一気に直してやろうと間違った気合を入れてしまいがち。
まずは自分が仲間のコードを読もう。そうすれば仲間も自分のコードを読んでくれるようになる
相手にやってほしければ、まずは自分がやってみせろ、ということ。
忘れても見たらすぐに思い出せるコードを書く
最後に出てくるこの言葉に全てが詰まっているように感じた。
人間は忘れる生き物で、今日の自分と明日の自分はまったくの他人。
忘れちゃいけない重要な部分を優先的に意識してコーディングしたり、
コメントを書くようにすれば、自然とクォリティが上がりそう。