この記事の目的
超有名な技術書”リーダブルコード より良いコードを書くためのシンプルで実践的なテクニック”．
実際にこの技術書を読んだ私が，この書籍学べること・学んだことの概略をまとめています．
購入を迷っている方の参考になれば，嬉しいです！
本の概要
はじめに
リーダブルコードは文字通り読みやすいコード．
理解しやすいコードやミスの起こりにくいコード，チーム開発で意識すべき点などコーディング周辺に関する様々な情報が書かれた良書になります．
実際のコードが載っていたり，具体例が書かれたりと非常に理解もし易いです！
この本をおすすめできる人
この本はコーディングをする人になら誰にでも必須な本になります．
しかし私が思うに，全くのプログラミング初心者ではなく，コーディングを大学の授業やプログラミングスクールで書いたことがある，これから実務経験を積む予定である人に非常におすすめできます！
これまで我流で書いてきたコードをもっと美しく書くには？ この名前意外と使っていたけど，ミスが起こりやすいんだ，，などの学びがたくさんあります！
私もその一人でした笑
また，現在ばりばりエンジニアとして活躍されている方も，一旦立ち止まってこの本を読んでみると多くの気付きもあると思います．
このようなプログラミング界における良書です！笑
読めば読むほど味が出る書籍になります．
ただしこの情報だけでは，具体的にどんなことを学べるのかイメージできてない方もたくさんいると思います．
そこで下記に実際に私がリーダブルコードを読んで見つけた発見・学びを断片的にまとめています！
購入する際の参考になれば嬉しいです．
リーダブルコードからの学び
命名規則｜名前に情報を詰め込む
命名規則に必要なのは，あとから見たときにすぐに理解できること．
それを実現するために必要な考え方がいくつかあります．
下記は自分なりにまとめたものになりますので参考までによろしくお願いします．
詳細を学びたい方はぜひリーダブルコードを読んでみてください！
ニュアンスも含めた明確な言葉で
例えばstop()
よく見る名前ですが，あまりよろしくはありません．
では変更すればよいのか．．．
取り消しができないのならば→kill()
再開できるなら→resume()
一時停止なら→stop()
このようにニュアンスまでも含めた明確な単語だと明確になります！
ある程度の英語の勉強も必要ですね笑
その他には，getもどこから取ってくるのかによって名前をfetchPage()などに変更する
などなどが挙げられます．
- send → deliver, dispatch, announce,,,
- find → search, extract,,,
- start → launch, create, begin, open,,,
- make → create, set up, build, generate, add, new,,,
単位や種類も明記する
たとえばtmp
これもtmp_fileなどのように中身までパット見でわかるようにする必要があります．
これはfor分で用いるi, j, kにも同様です．
i, j, kを引用する際に，どれがどれかわからなくなる→club_i, members_i, users_iまで具体的になにの数なのか明記することで明確になります！
更に，単位やフォーマットの情報も重要だと言えるでしょう．
例えばid，これも文字列なのか数値なのか16進数なのかぱっと見ではわかりません．．．
2進数であるならばhex_idというふうに，明記することでわかりやすいコードになります．
- delay → delay_secs
- size → size_mb
- limit → max_kbps
- password → plaintext_password
- comment → unescaped_comment
- url → untrustedUrl, trustedUrl
これらは単にわかりやすくなるだけでなく，危険予知(まちがえてクラッシュさせてしまったなどなどを防ぐこと)にも繋がります！
誤解を防ぐ表現
単位やフォーマットを関数名に含めることで，情報を増やすことができますが，
ブール値の場合は特に注意が必要です．
例えばread_password = true
これだとこれから読み取るのか，もう読み取っているのか曖昧です．
そこでis, has, can, shouldを使うことで解決できます．
use_is_authenticated，hasSpaceRight
こうすることでブール型だと明確に，そしてtrue/falseのどちらを指すのかを明確にすることができます．
応用内容として，ブール型とは関係ありませんが，下記の方法のような誤解を防ぐ方法もあります．
→→ローカル変数とメンバ変数を区別するためにあえてstatsとstats_と表記するような使い方をする．
勉強になりますね！
短くてもわかり易い表現
変数の名前に情報を詰め込むことは必要です．
しかし冗長すぎて逆に分かりづらくなることも想定されます．
そこで役に立つのが英語の前置詞です！
たとえば，ConvertToString()ならば→ToString()などです．
よく見る関数名ですね笑
このように省略も必要です．
ならば，どれぐらいの長さの関数名がベストなの？？
そう迷った場合は，スコープと連動するのが解決案に繋がります！
要するに，コードの行数が短ければ短い関数名，ながければ長い関数名です．
コメントアウト｜わかることは書かない
コメントアウトの鉄則は，コードから読み取れることはコメントアウトに残さない．
コメントアウトは多すぎても読みづらいし，少ないと説明書いてくれと思う．
そんな風に実は難しい作業です．
私としてはコードでどうしても表せないことをコメントに残す，これがいいのではないかと解釈しています．
コードに情報を詰めることが第一です．
つまり，コードをスムーズに読むことができるのならばコメントアウトはいらない！
命名するセンスが試されますね笑
ならば，コードでどうしても表せないこととは？？
たくさんあると思いますが，代表的なものは
罠を明記，コードの欠陥にコメントをつけるです．←コードが正義な気はしますね笑
// TODO: もっと高速なアルゴリズムに変える必要がある
// XXX: 実行時間はO(タグ×タグの深さの2乗)なのでネストの深さに注意
といった形です．
ちなみにTODO: などのアノテーションコメントは，テキストエディタ上で色がついたりすることで目立たせることができます．(エディタによって反応するアノテーションを設定する必要がある場合もあります)
アノテーションコメントはたくさんあり以下は有名なものになります．
- TODO: hogehoge → あとで手をつける，修正すべき点がある
- FIXME: hogehoge → 既知の不具合がある
- XXX: hogehoge → 危険！大きな問題がある
- WARNING: hogehoge → 注意が必要
- HACK: hogehoge → リファクタリングが必要
- OPTIMIZE: hogehoge → 無駄が多く、ボトルネックになっている
- REVIEW: hogehoge → 意図した通りに動くか，見直す必要あり
- CHANGED: hogehoge → コードをどのように変更したか説明
- NOTE: hogehoge → なぜ、こうなったという情報を残す
コメントアウトは最小限＝Gitみればわかることは書かなくていい
と考えると，5つくらいのアノテーションコメントで十分かもしれませんね．
他の項目
随時追加していきます！
comming soon…
おわりに
このブログでは，SwiftやFlutterなどの日々学びつつアウトプットしています．
他にもおすすめツールがあれば教えて下さい！
また，間違いや改善点があれば，ご指摘いただけますと幸いです！
