はじめに
今回は、リーダブルコードを読んで備忘録としてメモしておいた内容を共有します。
自分はエンジニア１年目の時に実装時のチートシートとして使用してました。
良いコードとは
プログラミングにおいて、短い行で書かれた頭のいいコード＝いいコードではない。
理解しやすいコードこそが良いコード。
読みやすいコードを書くことによって、バグを減らし保守性を高めることができる
自分しか理解できないコードを書くとコードの内容を忘れた頃の自分も苦労する
名前について
- 汎用的な名前を避ける。
- スコープが小さければ短い名前も可。
- 不要な単語を捨てる。例:
convertTostring→ToString - エンティティごとに異なるフォーマットを使用する。例: インターフェースはアッパーキャメル。
- 他の意味と間違えられない名前を付ける。
- Booleanの意味を明確にする。
- 名前を複数検討し、機能を知らない人にも伝わるかどうか確認する。
コードの見た目
- 一貫性のある改行をする
- 重複を削除
- 大切な部分を見やすく
- 縦の線を揃える
- 似ているコードは似ているように見せる
- 一貫性と意味のあるコードにまとめる
コメント
- コードを段落ごとに分割して要約コメントを入れる
- コードからすぐわかることは書かない
- 名前でわかりやすくできる場合は名前を変える。
- コードの欠陥にコメントをつける
- なぜその定数にしたか背景をコメントするとわかりやすい
- 初めて読んだ人が疑問に思う箇所にコメントを入れる
- コードの全体像のコメントを入れる
- 新たにプロジェクトに参加した人にわかりやすくする。
- コメントするよりも優れたコード
- ひどいコードを補うコメントよりもコードを改善する。
- コメントは領域を取りすぎないように
- 情報の濃度を濃くする。
- 曖昧な表現を避ける
- よくわからない引数はインラインコメントを付ける
ロジックの単純化
- 条件式の引数
- 調査対象を左、比較対象（変化する値）を右で統一する。
- 条件は肯定系を使用
- 三項演算子
- デバッガを使うときも使い辛くなるし、理解しにくいから普通に書く（賛否両論）。
- 三項演算子を使用して簡潔になるときは使う。
- ネストは浅く
- 早めに返してネストを浅くする。
- 巨大な式に対して
- 式の意味を説明する変数を使用する。
例:
// 改善前
if(line.split(":")[0].trim() === "admin"){
// 処理
}
// 改善後
const user_authority = line.split(":")[0].trim();
if(user_authority === "admin"){
// 処理
}
変数
- 役に立たない一時変数は使用しない
- 変数のスコープを縮める
- グローバルな変数をクロージャで包んでプライベートにする
- 変数操作の場所が多くなると判断が難しくなる
コードの抽出
- 関数に無関係な部分は切り出す
- 関数が独立すると汎用コードになり得る
- テストが楽になるかつ、他のプロジェクトでも使用できる。
まとめ
エンジニアなりたての時にリーダブルコードを読み、実装時にチートシートとして使用しながら実装を行ってました。
こちらが読んでくださったみなさんの役に立てば幸いです。