リーダブルコードを読んだので所感などを備忘録として残しておきます
翻訳版は Kindle 用の電子書籍がないようです
最初に
サンプルコードがいろいろ出るが JavaScript や Python など比較的高級言語で記載されているので読みやすい
C++ なども一部ある
そしてそれらが実際にリファクタリングされるプロセスが記載されているのでプロセスを理解することが重要だと感じた
過去に達人プログラマーを読んだがそれと同じようなことを言及している部分は多く存在したと思う
大事そうなことメモ
- 変数名はわかりやすく、スコープに応じて決める
- コードだけ見てわかる場合はコメントは不要、最初はコメントを書くことを意識すると良い
- ヨーダコード -> if 分の左辺に定数を記載して比較と代入演算子の記述バグを発見する方法
- 気になったことをコメントに書いても OK、バグになりそうな箇所や計算量に課題がある箇所など
- 関数名はそれを見ただけで何ができるのかわかるような名前が望ましい
- 関数名はユーザが暗黙的に想定している命名規則を使う場合にそれに応じた計算量や値の取得ができるようにしなければならない
- 例えば GetHoge はフィールドである hoge を返すだけの関数であったり size 関数は配列やハッシュの長さを返すだけの処理にする
- DeleteHoge のような関数の名前で実は削除はしていないで空の値を設定するだけみたいな実装はよくない
- 言語のコーディング規約がある場合はそれを使う、チーム内で決めても OK、とにかく一貫した書式を使うこと
- 比較する場合は左辺に変化しずらい比較対象の値を設定し右辺にインクリメントしたりするような値を設定する
- 否定の否定は使わない (
if (!disable)的な) - ド・モルガンの法則を覚えて比較式を簡単に変換できるようにしておく
- guard 記法を積極的に使う
- Don’t repeat yourself (DRY) の原則はリーダブルコードにも何回か出てきた
- 汎用コード (
util/) となる部分を素早く見つけすぐに切り出せるようにする - 長いタスクを短いタスクを列挙し関数やクラスなどに分割する
- テストが見やすいコードは読みやすいコード
- できる限り言語の標準パッケージを使う
- まずはやってみる、試してみる、そしないと何も始まらない
これらを踏まえて疑問に思ったことや所感的なことを以下に記載します
golang や Swift はリーダブルコードで指摘されていることを言語レベルで吸収してくれる言語なのかもしれない
特にスタイルに関してだが、例えば「段落を使ったり複数行に分けて書く」とかは go fmt で自動でやってくれるのでコーディングしている側はそこまで気にしなくて済む
大文字小文字でスコープの範囲を指定できるのでその点も見た目だけで判断できる
ただ golang にはラベルを使った goto があり本書では goto を嫌っていたのですべてが理想な言語というわけでは当然ないと思う
Swift も同じような印象で例えば if let などは使用する変数のスコープを最小限にするための機能でそういった場合は自然に変数名が短くなると思う
Optional/Unwrap 型も見ただけで NULL の可能性が判断できる
コーディング規約などは IDE などでも統一できると思う
インデントや行間、1 行の最大文字数などは IDE を使って統一することもできると思った
IDE が嫌な場合は rubocop などのコード解析ツールを使っても良いと思う
やりすぎはダメというがやりすぎかどうかの判断が難しい
おそらく経験しかないと思う
あとは好みだろうか
テストについてもやりすぎは良くないと指摘している
個人的にはテストは嫌いなのでやりすぎるということはないと思う
リファクタリングやテストを優先してコードが増えないようにしたい
基本的にはリーダブルコードはコード量を減らすパターンが多いが状況によってはコード量が多くなるケースもあると思う
特にテストのためにリファクタリングしたりモックなどのコードが増える場合もあるので気をつけないとダメだと思う
使われていない通っていないロジックを評価する仕組みを入れておきたい
不要なコードがある場合は実装しない/削除したほうが良いと本書にもあるがそれを判断するための仕組みを入れておいたほうが良いと思う
基本的にはログで良いと思う
プロファイリングというかバグトレースなどのツールでも良いと思う
削除する基準はわからないが 1 年以上使われていないロジックなどは一生使われないイメージがある
でも初めから実装しないという手段を取れるのであればそれが一番だと思う
最終的には「好み」だと思う
変数の名前は関数の名前は特にそうだと思う
もちろん本書で指摘されているケースと全く同じケースだった場合には気付けると思うがそうでない場合がほとんどで、そういったケースはもうコーディングしている本人やレビュワーの好みに完全に左右されると思う
do-while は極力使わないという記載もあったが正直これも好みなので使っても全然良いと思う
リファクタリングやテストと同じできりがないとことだと思うのである一定のレベルでリーダブル化することやめないとダメだと思う
最後に
これを読んで実際にリーダブルなコードにリファクタリングしなければいけないケースに遭遇したときにすぐに実践できるレベルになっていなければダメだと思う
ただ、本書を読んですぐにそういう風な人になるということはなくやはり経験を積まないとダメだと思う
本書のパターンを記憶しておくのも有効な手段だとは思うがそれよりも実際の経験を積むほうが体にリーダブルなコードを書くクセがつくので良いと思う
2 回目以降に同じように読み直すのも良いがリファクタリングのサンプルコードだけを見直したり好きな章や気になる章を読み直すだけでも良いと思う
0 件のコメント:
コメントを投稿