はじめに
新卒1年目のエンジニアですが、上司に勧められリーダブルコードを読みました。
そこで感じたことを簡単にまとめてみる記事です。
というのも、技術書って読んでいる間は勉強になりますが読み終えると何から意識しようか、とわからなくなります。
ですので、初心者エンジニアの私が初めてこの本を読んだ時に、まず意識できそうだと思ったところをまとめました！
「カラフル」な単語を探す
コードを書く際に似たような英単語を何度も使ってしまうと思うが、より適切な、具体的な単語がないかを検討するべき。
シソーラス（類語辞典）を使って調べたりできるらしい。
なにかを返す関数には、getから始まる名前をつけてしまう。
しかし、通信を伴う場合にはfetch、簡単な計算をするならcalculate、データをそのまま返す時にget。
このように使い分けをすることで、処理の中身を見なくても読み手に処理の大枠を伝えられる。
以下、書籍にある単語の例。
| 単語 | 代替案 |
|---|---|
| send | deliver, dispatch, announce, distribute, route |
| find | search, extract, locate, recover |
| start | launch, create, begin, open |
| make | create, set up, build, generate, compose, add, new |
いつも無心で知っている単語を使ってしまっているため、Copilotに一度関数名の案を出してもらったりして、より適切な言葉を探すステップをたまに踏んでいく。
変数を削除する
中間結果を保持するためだけに使っている変数は、なるべく削除する。
- 使用する直前に定義し、変数のスコープを縮める
- すぐにreturnできるものはしてしまう
ということも意識しようと思う。
一方で、変数に一度だけ書き込む、というのがGolangでの実装で未だわかっていない点である。
自分の考えを記録する
処理を追いづらい箇所でコメントを残すことが多いが、それは、できれば命名やコードの読みやすさによって解決したい。
それよりもコメントで重要なのは、自分の考えを記録すること。
- 一見もっと高速な処理がありそうだが、なぜ今のように実装したのか？
- 定数をどのように決定したのか？
- リファクタが必要な箇所やエラーが起きうる箇所など、コードの欠陥があるならそれも書いておく
それによって、後から開発する人が同じ余計なステップを踏まずにタスクへ取り組むことができる。
例えばこのような事柄について、TODO, FIXME, HACK, XXXからはじまるコメントを書いておくのが良い。
VSCodeであればTodo Treeなんかを使ってこれらのコメントは一覧で見ることができる。
このようなコメントを書いておくことで、自分で実装している間にも修正すべきところが見えてくるし、機能を実装し終えた上で改善点を見直すことができる。
何より、コメントに残しておくことで、記憶しておくための余計な労力を使わずに済む。
その他
開発においてCopilotは手放せないが、例えばその提案をそのまま受け入れているコーディング箇所、ひたすらTabを押し続けている箇所は関数として切り出せそうだと感じた。
まとめ
初めて読むと、以上のような、言われてみると当然のことばかり印象に残っている。
また、印象に残っているといっても書籍に目を通しながらでないと学んだことをまとめられない。
コードレビューなどを通してコーディングでより多くを意識できるように努めたい。