【永久保存】リーダブルコードの感想文の感想文を書いてみた!

こんにちは、そうまっちです。

プログラマーの基本中の基本がリーダブルコードという本に詰まっているようで。

先輩エンジニアにも1年に1回は読み返したほうがいいと声を大にして勧められました。

ライターのバイブルが「神話の法則」で

ナンパのバイブルが「ザ・ゲーム」と言われるように

エンジニアのバイブルが「リーダブルコード」なんです!

 

でも飽き性で金欠でプログラミングの知識もほどんどないのに手を出していいのか?

と思いリーダブルコードを簡単にまとめてくれた方達の記事を読んで感想文を残そうと思います。

 

皆さん経験あると思うんですけど、

小学生の時によく友達の読書感想文をよんで感想を書いてたじゃないですか?

それです。

参照感想文

https://qiita.com/otsukaaaa/items/4f6e449d79d6feac834a

https://qiita.com/gfmc12345/items/b140e1ee6a6e3c64e687

https://blog.y-yuki.net/entry/2016/09/06/202907

https://qiita.com/fkrw/items/7646563a2b238fbcff9a

 

リーダブルコードとは?

より良いコードを書くためのシンプルで実戦的なテクニック 

  • 君のコードをよくすること
  • コードは理解しやすくなければならない

1章 理解しやすいコード

自己満のコードはオナニーと一緒です。

ツイッターで好きな人に思いを伝えるように。

最短(時間)で最小(コード量)な情報で伝えるのが大切。

※Twitterの文字制限は280文字

 

2章 名前に情報をつめこむ

汎用的な名前は避け、名前に情報を詰め込む。

長い名前は問題ではない。

※大学の卒業論文みたいにタイトルだけで内容の9割は分かる。

余談ですが、私の卒論タイトルは「糖尿病患者で過剰発現しているPEPCKを抑制する新規化合物の探索」でした、どんな内容かタイトルだけでわかるりますね。

 

3章 誤解されない名前

  • 名前が「他の意味と間違えられることはないだろうか?」と何度も自問自答する
  • 限界値を示すときは min_ max_を使う
  • 範囲を示すときは first_ last_を使う
  • 包括的範囲には begin_ end_ を使う
  • getXXXXは変数へのアクセッサの意味として認知されているのでそのような処理以外でこのメソッド名を使用しないこと

 

4章 美しさ

インデントが整って適切に改行された美しいコードを目指す。

プログラマーのほとんどはコードを読む時間なので、読むならわかりやすい美しいものがいいよね。

一貫性が大事、大人数が関わるプロジェクトでは自分の個性派出さず同調して第三者がみて一貫して読みやすいコードを目指す。

空行をつかって適切なブロックに文を直す

 

5章 コメントすべきことを知る

コメントを読む時間はコードを読む時間に当てたほうがいい

スティーブジョブズが毎朝鏡に向かって「もし今日が自分の人生最後の日だとしたら、今日やる予定のことを私は本当にやりたいだろうか?」と問いかけ、答えが“NO”の日が幾日も続くと、そろそろ何かを変える必要があるなと悟る話は有名で、コメントも本当に必要なのか自分に問いかけましょう。

 

6章 コメントは正確で簡潔に

情報密度の高い言葉を使う

 

7章 制御フローを読みやすくする

関数で複数のreturnを使ってはいけないと思い込んでるのは間違い

早めにreturnすることで「ガード節」をつくる。

 

8章 巨大な式を分割する

  • 説明変数を用いて分割する
  • 要約変数を用いて分割する

9章 変数と読みやすさ

  • 「グローバル変数を避ける」というのは当たり前のルールとして認知されている
  • 変数をまとめて定義するのは見やすいと思いがちだが覚えておく必要があるので、基本的には使う直前に定義する
  • 変数のスコープ(生存期間)は長いとコードを追いかけにくい。

10章 無関係の下位問題を抽出する

目的:プロジェクト固有のコードから汎用コードを分離する
メリット:汎用問題から切り離された境界線上の明確な業務固有の問題に集中できる

 

11章 一度に1つの事を

タスクを異なる関数に分割すること。

 

12章 コードに思いを込める

コードを書く前にロジックを説明できるようにする。

 

13章 短いコードを書く

もっとも読みやすいコードは何も書かれていないコード?!

 

14章 テストと読みやすさ

テストコードも読みやすさが大切。

テストしやすいようにコードを設計する。

 

15章 「分/時間カウンタ」を設計・実装する

外部の視点を得る事、コードが「ユーザーフレンドリー」かどうかを確認できる。

第三者の第一印象を聞く、数ヶ月後に自分で見返すなどしてコードの可読性を保つこと。

 

まとめ

いいコードを考える前に、こんあコードは嫌だ!と考えて見ると。

  • 読みづらい
  • 動きがわからない
  • 見ただけで拒絶

こんな理由が上がるだろう、逆にいいコードはこの逆でありリーダブルコードでは詳しく書いてあるそうだ。

結局は可読性が保たれるようなコードは個人差があって品質を均一にしようと考えたときに、みんなでリーダブルコードのルールをスタンアードに考えたら均一化されるよねって話だとおもいます。

 

以上、感想文の感想でした。