胃弱だより

セキュリティとかに興味ある感じの雰囲気あいおーてーエンジニアのブログ

リーダブルコードを読んだ

めちゃくちゃ今更ながら、駆け出しエンジニア Advent Calendar 2018 - Qiitaに参加させていただいていたのに、投稿していなかったので投稿します🙇‍♂️

リーダブルコード自体は結構昔に読んだのですが、改めて読み直してまとめてみました。

以下は Dustin Boswell氏・Trevor Foucher氏著 角 征典氏翻訳の”リーダブルコード より良いコードを書くためのシンプルで実践的なテクニック”のまとめです。

 

#リーダブルコード

優れたコード
 理解するまでに時間のかかる短くてかっこいいコードよりも、理解するまでにかかる時間の短い分かりやすくて長いコードの方が優れている。
読みやすさの基本定理
 コードは他の人が最短時間で理解できるように書かなければならない。他の人というのは数ヶ月後の自分も含むので、例え自分しかいないプロジェクトだったとしても、未来の自分の為にも読みやすく書くべきである。
感想:自分しかいないプロジェクトだとしても、将来的にプロジェクトを誰かに引き継いでもらう時にコードの可読性が低いとすごく大変なので、可読性はどんな時にでも重視する必要があると感じた。
表面上の改善
 変数名や関数名などは分かりやすさを心掛ける。分かりやすさとは、名前を見ればどういった振る舞いをしているのかが分かる混乱のない名前のことを指す。混乱のない名前とは、誤解を与えるような抽象的な名前や、語弊のある名前でないことである。
 ただし、スコープが小さい時は短い名前でも良い。
 頭文字や省略形は、新しく入ってきたチームメイトでも理解できるのであれば問題ない。
美しさ
 見た目が美しいコードの方が使いやすいのは明らか。一貫性のある簡潔な改行位置や文字を整列させることで、視覚的な可読性が向上する。また意味を持つコードごとに単位や段落で分けることで、コードを理解しやすくする。
一貫性
 もし途中で参加したプロジェクトのコードが間違ったスタイルだらけだったとしても、正しいコードを書くよりも一貫性を優先させた方が良い。
コメントするべきこと
 コメントが長ければ長いほどコードを読む時間が減ってしまうので、価値のないコメントは書かないようにする。例えば、コードを読めば分かるようなことは書くべきではない。
 名前のせいでコメントをつけないといけない時は、名前の方を変える。
 自分の考えを記録する。
 コードの欠陥にコメントをつける(TODO, FIXME, HACK, XXX)
 ハマりそうな罠を告知する。
 入出力の実例をかく
 コメントは長々と書かずに簡潔に書く
制御フローを読みやすくする
 条件は肯定形で書く
 単純な条件を先に書く
 ネストは浅くする
とにかく、実行の流れを追えるコードを書くこと
巨大な式を分割する
 説明変数…処理の前に変数に代入することで、意味を分かりやすくする
 要約変数…式を変数に代入しておくことで、コードを短くする
 巨大な式を分割し、本質を理解しやすいコードを書く
変数と読みやすさ
 コードが読みやすくならない変数は削除する
 結果を保持するだけの変数を使うよりも、早く結果を返す
 制御フロー変数を使わない
 変数のスコープを縮める
 変数の変更箇所は出来るだけ少なくする
無関係の下位問題を抽出する
 エンジニアリングとは、大きな問題を小さな問題に分割して、それぞれの解決策を組み立てること
 高レベルの目標に直接的に効果がないコードは別の関数に切り出す
 プロジェクト固有のコードから汎用コードを分離する
一度に一つのことをする
 ・コードが行なっているタスクを一覧に挙げる
 ・タスクを出来るだけ小さく異なる領域に分割する
コードに思いを込める
 書こうとしているコードを簡単に言葉で説明する
 実装は最低限にする
 標準ライブラリに慣れ親しんでおく
テストと読みやすさ
 テストコードの読みやすさ=保守のしやすさ
 テストコードが複雑だと、テストコードを書き換えることを恐れて本物のコードを書き換えなくなってしまう
 最小のテストコードを作成する
 エラーメッセージを読みやすくする
 入力値を単純化する