__7_リーダブルコード

【読書感想文】『リーダブルコード』を読みました📚

こんばんは、ワタコーです。

今回はいつもと雰囲気が変わって技術書の読書メモです。

ここから先はコーディングに興味のある人がメインで書いていきます。もちろん、個人の読書メモなので解釈が間違っている場合はコメントで教えていただけると幸いです。

今回の図書はこちら

僕の研究室には私物を含めて4冊以上転がってます(笑)

なので、ありがたいことに無料で読ませていただきました(感謝)



英語ができるメリット



プログラムを書き始めた当初(2017年の4月頃)は、「英語が出来ること」と「プログラムが得意」なことは全てが別物だと思っていたんですね。

ところがどっこい。英語を知っている人がスペイン語を学ぶのと一緒で役立つ部分があります。


変数名の付け方



リーダブルコードでは、変数名を付ける際にシソーラス(類語辞典)を使うことを推奨しています。例えば

makeの類語:create, set up, build, generate

といった、クラス(関数)が何かを「作る」のにも色々な「作る」があります。この時、英語を学んでおくと一般的に単語が示す意味を知っているので、かなりアドバンテージがあります。もちろんみんながリーダブルコードの理論に乗っ取ってくれればの話ですが・・・(ぜひ!)

generateは個人的に見やすくて好きですね。
0からこの関数を使った際に新しいものを生み出してる感じがします。



変数名はコメント



つまり、変数や関数を見ただけで、その中身が分かるコードは最強な訳です。結局「伝える力」を身につけるとここにも活きると思います。

これからの話(関数)は、こういう目的がありますよ!

みたいなイメージですね!


丁寧過ぎてもいけない



とはいえ、変数名の付け方を丁寧にしようと思うと、長く、ながーく、命名してしまう気もする・・・かと言って変数名はコメントだから丁寧に書かなきゃいけない・・・長い変数名は単語補完機能があるため問題ではなく、問題なのは「長過ぎて読みたくない」「長過ぎて理解できない」ことが問題だと書いてありました!



不要な単語を投げ捨てる



結局は、ここに行き着きます。論文を書くときも、

〇〇であることが分かり、□□だとなりそうだが、実際は△△である。

という文章があった時に

〇〇であるため、△△である。

で言いたいことは伝わる。つまりは伝えたいことに対して無駄なことを省略していくことが大事!



似ているコードは
似ているように見せる



なるほどな!と感じます。論文も今までの論文を参考に似たような書き方をすると、これまで論文を読んで来た人がスムーズに読んでくれるのでそれを意識して書くと、結構査読結果が良かったりします!(こないだ通った論文の査読コメントが高評価で嬉しかったのは余談)


価値のないコメントはしない



これは気をつけないと・・・全部にコメントしてた時期あるけど確かに読み直した時要らないコメント多かった。。。気をつけよ。。。



他の人も引っかかりそうな所を
コメントする



自分がコードを書く際に躓いたところだけでなく、読み手が分からなくなりそうなことをコメントで教えることが大事です!頑張って親切心輝くコード書いたんで!!(自分はまだLV1のヒトカゲです)



条件式の左側に調査対象の式
(値が変化する式)を置く



a > b と b < a は意味が同じだが、リーダブルコードでは見易さを良くするにはa(調査対象)b(比較対象)とした時に a > b が見やすいと話している。これも

if my_age > 18(もし私の年齢が18歳以上ならば)
if 18 < my_age(もし18歳が私の年齢以下ならば)

だと明らかにmy_ageが左に来ている方が見やすい。
これが基準。当たり前だけどスッキリします。



条件式は否定形よりも肯定形を使う



否定形だと書いてあることを一度引っ繰り返す作業をします。これだと考える処理が一つ増えます(人によってはそんなことない?)個人的には納得です。



ネストの深さは浅く



if {if {if }}} は避けたい。一個前のifを思い出すのに労力が掛かる。



巨大な式を分割する



条件式に組み込む前に変数を作ってあげる。
(条件式を見る→わからない変数名がある→変数名を確認する)



変数は一度だけ書き込む



絶えず変化する変数は読み手にはしんどい。


不必要な機能はプロダクトから削除する



色々、便利な機能があって賢い人が使うと嬉しいだろうけど万人ウケするのはシンプルなこれっていう機能のみ!インスタは写真をあげるだけ。TikTokは短い面白い動画を撮るだけ。コードもそれにあった最小限の機能。納得です。14章(テストコード)はまた読み返す。

初の技術書のまとめをしてみましたが



技術書の読書メモ難しい




自分が理解してない部分がめっちゃ分かるしスラスラ読める所と読めないところが、ブログを書くと分かる(めっちゃいい)。

(ダンベルと一緒で)もっと難易度の高い技術書を読むぞ!


参考になった方はイイネ。もう読んだけどここが重要なのに見落としてね?って方はコメント。ぜひよろしくお願いします。

ワタコーでした!

この記事が気に入ったらサポートをしてみませんか?