くわこのpermission denied.

WEBエンジニアの僕がぶつかった技術的な問題や発見

リーダーブルコードを読みました【まとめ】

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

新卒エンジニアとして入社してそろそろ1年が経とうとしているので、初心に帰って『リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

を読み返してみた。
ちょうど1年くらい前にも読んではいたのですが、同じ内容とは思えないくらい学ぶことが多かったので、エッセンスだけ抽出したものをメモがてらに共有します。


副題にあるように、「より良いコードを書くためのシンプルで実践的なテクニック」を身につけるための一冊。
内容的には、経験あるエンジニアなら「まあそうですよね」と思える内容が多く新しい気付きが多かったかと言われるとそうでもないですが、改めて言われると「最近できてないな、改善しよう」と思える部分が多かったです。

共感した部分まとめ
4章:美しいコード
複数のコードブロックで同じようなことをしていたら、シルエットも同じようなものにする。
・コードの「列」を整列すると概要が分かりやすくなる
・空行を入れて、大きなブロックを論理的な「段落に分ける」

5章:コメントすべきことを知る
・コメントすべきで「ないこと」
 ・コードやメソッド名からすぐ分かるようなこと
 ・ひどいコードを補う補助的なコメント
・コメント「すべき」こと
 ・なぜこのコードが他のやり方ではなく、こうなっているのか
 ・コードの欠陥をTODO: で覚えておく
 ・定数の値にまつわる「背景」

6章:コメントは正確で簡潔に
・こそあど言葉を使わない
・コメントに含める入出力の実例を慎重に選ぶ
・コードの意図は高レベルで記述する
・よくわからないコメントにはインラインコメントを使う

7章:制御フローを読みやすくする
・条件やループなどの制御フローはできるだけ「自然」にする

11章:1度に1つのことを
・読みにくいコードがあれば、そこで行われているタスクを列挙し、別関数にに分割できるタスクは別関数にしてしまう。それ以外は関数の論理的な「段落」にしてしまう。
・タスクをどのように分解するかよりも、分解すること自体が大切である。

12章:コードに思いをこめる
・説明的なコードを心がける。

13章:短いコードを書く
・プロジェクトを開始する際、プロジェクトに書かせない機能を過剰に見積もってしまう。その結果、多くの機能が完成しないか、全く使われないか、アプリケーションを複雑にしてしまう。
プログラマは、実装にかかる労力を過小評価してしまうものである。プロトタイプの実装にかかる時間を楽観的に見積もったり、将来的に必要になる保守や文章化などの負担の時間を忘れたりする。
・多くのプログラムが100%正しくてあらゆる入力を正しく行う必要は無く、要求を詳しく調べれば、もっと簡単にできることもある。短いコードで実装できることは短いコードで実装してしまおう。
・面倒だが、未使用コードは削除する。
・冒険。興奮。ジェダイはそんなものは求めておらん ーヨーダ
・定期的にAPIを読み、標準ライブラリに慣れ親しんでおく。

コラム:外部の視点を得る
・外部の視点を得るというのは、コードが「ユーザーフレンドリーか」どうかを確認する優れた手段である。素直に他人に第一印象を聞いてみよう。「他人」には6ヶ月後の自分も含まれている。


まとめと書きながら割と長めの文章を書いてしまいました笑