リーダブルコードを読んでみて

エンジニアが読むべきと言われているリーダブルコード

何回でも読んでも使える内容、今後エンジニアとして活動するなら教本としてずっと持っていていい本だと思うが、
ちゃんと読めてなかったところ、読み返すと忘れていたところもあったのでの要点などまとめて忘れないようにしたいと思う

1章 理解しやすいコード

優れているコードは「他の方が最短時間で理解できること」
この書籍のテーマである

コードは短くしたほうがいいが、「理解するまでにかかる時間」を短くする
ほうが大切

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

この章では、関数名や変数の名前の付け方について、以下の内容について記載されていた

● 明確な単語を選ぶ
● 抽象的な名前よりも具体的な名前を使う

 getPageという関数名があった場合、　「get」という単語どこから取ってくるのか？などわからない、DownloadPage()の方が分かりやすい

● 汎用的な名前を避ける（あるいは、使う状況を選ぶ）

tmpを一時的に使うのはいいが、様々な箇所使い、コード上の生命時間が長い場合、tmpの中身がパッと見ただけではわからなくなる
処理の中で煩雑にせず明確な理由を持って使うべき

● 接尾辞や接頭辞を使って情報を追加する
● 名前のフォーマットで情報を伝える

時間を表す変数でstartという変数を作成した場合、その変数の単位の時間を使用するのかわからない
この場合はstart_msなどにするべき
また、変数をつける際、フォーマット（キャメルケースなど）に沿ってつけると理解しやすい

3章 誤解されない名前

最善の名前というのは、誤解されない名前である。誤解されない名前かどうかを想像してみよう。

上下の限界値を決めるときには、max_ やmin_ を前に、
包含的範囲であれば、first やlast を
包含／排他的範囲であれば、begin とend
ブール値だとわかるようにする場合はis やhas

名前の付け方次第で何をするものか誤解されないようになる

4章美しさ

この章では、一貫性と意味のあるやり方でコードを「整形」することにより、素早く簡単にコードを読むことを目的に記載されていた

• 他の箇所のコードの記述方法に合わせて、コード追加したものも統一する、インデントを揃える

• 変数や関数は重要度順、ABC順などを意識にして並べる

• 空行を使い大きなブロックは「段落」にわける

5章コメントすべきことを知る

コメントの目的は、コードの意図を読み手に理解してもらうこと

コメントでは、

• コードからすぐ読みれることはコメント化しない

• 酷いコード（関数名が意味に合っていないなど）を補う「補助的なコメント」が書かれていた際、コメントで補うのではなく、コードの改修がベスト

また、コメントを書くべきことは、

• なぜ他と違う書き方になっているのか説明するコメント(監督コメンタリー)

• 関数の値の[背景]についてコメントする

また読み手を考え

• 読み手が疑問に思うであろうところを予測しコメント記載

• ファイルやクラスは「全体像」のコメントを

• 読み手が細部まで読むのに時間取られないように、コードブロックには概要のコメントを

6章 コメントは正確に

コメントを書く際は

• 「それ」「これ」などの代名詞を避ける

• コメントは簡潔に保つ

• 関数の動作は正確に

#改善前
//このファイルに含まれる行数を返す

#改善前
//このファイルに含まれる改行文字(\n)を数える

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

ifなどの条件式が関わる場合

・条件式の引数の並び順は左側に「調査対象」で右側に「比較対象」
・if~elseで条件式がいくつか並ぶ場合は肯定式から

ループ処理など繰り返す処理の場合
・三項演算子(?:)、while,gottoは読みづらいので使わないように
・ネストが深いとコード読むのに力を使う、ネストは浅くして簡潔に「直線的」なコードに

8章 巨大な式を分割する

巨大な式(長い式)は理解するのに時間がかかる
説明変数(式を表す変数)を使用すると理解が早まる

#改善前
if(line.split(":")[0].trim() === "test"){

#改善後
tmp = line.split(":")[0].trim()    #ここの部分が説明変数
if(tmp === "test")

複雑な式はより優雅な方法を見つける

#改善前
var test = function(){
  return (b > ob && b <ob) || (e > oe && e <= oe) || (b <= ob && e >= oe)
}

#改善前
var test = function(){
  if(oe <= b) return false;
  if(ob <= e) return false;
  
  return true;
}

9章 変数と読みやすさ

大きな要点は以下の通り

• 不要な変数を削除する

• 変数のスコープを縮める

• 一度だけ書き込む変数を作成

以下のコードのように説明変数にしなくても、関数で意味がわかるものは、変数用意するのではなく、無くして直接代入する方がよい

const now = datatime.now();
const root_message.last_view_time = now

また、処理を分割しグローバル変数(関数)を作るのはいいが、処理の中で使用していないものがあれば削除しスコープを縮めるべき

同じ名前の変数を処理の中で使いまわしていた場合 (tmp)、読んでいる際、理解するのに時間がかかる
一度だけ書き込むようにすると、読み手の理解は深まる

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

無関係の下位問題を積極的に見つけて抽出すること

プロジェクトの固有のコードから汎用コードに分離することが大切
一般的な問題を解決する関数やライブラリを作っておけばプログラム固有の小さな単位で読むことができ理解が早い

11章 一度に１のことを

コードを構成する簡単な技法「一度に 1 つのタスクを行う」
こちらについて書かれている内容でした

それを行うための手法として以下のことを行うことを紹介されていた

• コード内の「タスク」をすべて列挙

• タスクをできるだけ異なる関数に分割する。少なくとも異なる領域に分割する

本書には、ユーザの所在地を読みやすく文字列([都市、国])に整形する１つの処理について例が書かれており、その処理の中でも
「locationの値の抽出」「都市を作る部分」「国を作る部分」「更新」など分割することができた

読みにくいコードは、タスクを分け、分割し関数化することにより、読み手の理解が早まる、プログラムが行っているこを正確に説明することが大切

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

コードの読み手のことを考え「簡単な言葉で」書くべきである
そのための手順として以下が紹介されていた

• コード動作を同僚にも分かるような言葉で説明

• キーワードやフレーズに注意

• その説明に合わせてコードを書く

13章 短いコードを書く

新しいコードには保守が必要になり、コードが増えると重くなり、問題も発生することも多い
できるだけコードをこの章では説明されていた

• 過剰な機能を持たせないために、不要な機能をプロダクトから削除

• 最も簡単に問題解決できるように考える

• 定期的にAPIを読んで、標準ライブラリに慣れておく

コードのスリム化や簡単にする方法はいくつかの章でも触れていたが、ライブラリについてはあまり他のところでは触れられてなかったので印象深い

日常でプログラミングする際、標準ライブラリで解決できるのに知らず、また、忘れて難しいコードになることもあるだろう
それを防止するため、定期的にAPIやライブラリを読み触れておき、対応するようにすべきである

14章 テストと読みやすさ

スッキリ効果的なテストを書くことについて書かれていた
※テストの重要性や、テスト駆動開発などについては触れられてない

テストコードを改善するためには、

• テストはできるだけ簡潔に、入出力のコードは１行で記述できるとよい

• テスト失敗の場合、バグなどは発見しやすいエラーメッセージを表示するとよい

• テストには単純な入力値を使う

• テスト関数は何のテストなのかわかる名前にする。[Test_<関数名>_<状況>]のような形で

感想

読んでみると理解するのに時間がかかる箇所、やっていたが抜けていた部分など多かった

今後の開発に生かしていきたい
あくまで、今回は自分が読んでの理解なので、再度読んで解釈が違った場合は、その都度変更していきたい