2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

リーダブルコード 個人的読書メモ

Last updated at Posted at 2021-12-10

リーダブルコード

――より良いコードを書くためのシンプルで実践的なテクニック

3年ほど前に購入した時に一読したのですが、あらためて読みました。
前半は読みやすく、後半からコードを追うのが難しい箇所があり、時間がかかりました。
読書したときのメモや感想をまとめました。

理解しやすいコードを書く

  • コードは短いほうがいい
  • ただし、理解しやすいコードのほうが大事
  • コードは理解しやすい前提で短い方がよい

名前は重要

  • いい名前をクラス、メソッド、関数、変数につける
  • たとえば、単にgetではなくてget以外の何をgetするのかがわかる単語に変えたほうがよい
  • もしくはget+動詞とか
  • 基本的には、名前に一時的以外の情報がないtmpは避ける。tmpを変数や返り値の変数に使うと何を返すかわからないので意味のある名前がよい
  • ただ、変数のスコープが狭く(3行とか)、用途が明確な場合には使ってもいい
  • for文など繰り返し処理内でiなどの変数を使うのがいいが、複数同じ用途の変数がある場合は、iではなくitems_iなど他のものと区別できるものがいい
  • 意味がわからない省略した名前を使ってはいけない
  • スコープがせまくて、使用する箇所が近くにあって用途がわかる場合であればよい
  • 短くしても意味がわかるものは、短くする (例)convertToInteger() を toInt()

見た目の美しさ

  • インデント重要
  • 複数連続で定義する変数や配列の中身の定義だと縦に揃えるととても見やすい
  • 並び順に意味をもたせる。並び順には理由があるとよい
  • どんな理由でもよいが、できれば、他と統一性があるとよい

コメント

  • コードを読んですぐにわかるものにはコメントを書かない
  • 読んですぐにわからなそうなコードにはコメントを書く
  • そのほうが早く処理を追うことができる
  • 短い簡潔な文章であっても全体像がおぼろげでもわかるコメントがあるとよい
  • 新しくプロジェクトに入り、全体像がわからないとつらい
  • ソースをがんばって読むよりも処理の要約がコメントされていたほうが時間がかからない
  • コメント中にそれやこれといった代名詞が何を指していないかわからない場合に代名詞を使わない
  • 代名詞がひとつしか刺さない場合は使ってもよい
  • メソッドの引数と返り値の例を示すと分かりやすい場合がある

if文について

  • if の左側に変化する。右側に変化しない値を持ってくると読みやすくなる
# コード例
if (length > 0) {
  // なんらかの処理
}
  • ifは基本、肯定が先、否定があと
  • 否定が主な場合は、否定が先
三項演算子
  • 条件が単純で1行で読みやすくかける場合は、三項演算子を使う
  • ガード節や変数への代入で使うと便利
  • ネストが2重以上で、複雑で分かりづらい場合は、if/ elseのほうがよい
  • 三項演算子のデメリットはデバッガーでデバックしずらいこと
ガード節
  • 早く返すと読みやすくなる場合は、ガード節を使う
# コード例
def hoge(params)
  return false if params.nil?

  # 以下、なんらかの処理

end

ネスト

  • true/falseを返す関数では、ifの中にifを書くようなネストの深いコードを書くよりif文の中で早めに都度returnさせたほうがネストが浅くなって読みやすい
  • ifの中にifを書くよりも、ifをふたつ書いた方がよい

変数のスコープ

  • 変数のスコープは小さくしたい。変数を変更する際に、影響範囲が小さくなって読みやすくなる

メソッドの分割

  • そのメソッドの上位の目的ではないものは、関数を分けて抽出する
  • 読みやすくなるし、再利用できるかもしれない
  • メソッドにひとつのことをさせると単純に読みやすい
  • 覚えることが少なくてすむ

コードを書く前に

  • 人に説明するつもりでやりたいロジックをシンプルに整理する 

コードを書かない

  • 要件を確認して、簡単な実装にできないかを考える
  • コードを書かないのが一番バグがない
  • ライブラリがあれば自分で書かないで、それを使ったほうがよい

テストを書きやすくする

  • クラスを小さく
  • クラス、メソッドがひとつのことをしている
  • クラス同士が依存が少ない

全体的な感想

原文もそうだと思うのですが、文章が優しく、翻訳も優しくて、読みやすいです。
15章「分/時間カウンタ」を設計・実装するぐらいから僕は急に読むのが難しくなった印象があります。

サンプルコードも多くの言語で書かれていて、自分の好きな言語、得意な言語が出てくるとうれしいですね。

随分前に一回読み、内容を忘れていたのですが、確かに自分の中に無意識にやっていたことがありました。
コードを綺麗に読みやすく書くのは、自分の中で優先順位が高いのでネットの記事や他の書籍等でも読んでいるので、そこで重複してるかもしれませんが。

2
1
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
2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?