リーダブルコード

2021/7/31 13:442022/8/14 7:25

Memo はじめに 1. 理解しやすいコード 2. 名前に情報を詰め込む 3. 誤解されない名前 4. 美しさ 5. コメントすべきことを知る 6. コメントは正確で簡潔に

TOPICS Programming ,Business/Essay 発行年月日 2012年06月 PRINT LENGTH 260 ISBN 978-4-87311-565-8 原書 The Art of Readable Code FORMAT Print PDF EPUB 美しいコードを見ると感動する。優れたコードは見た瞬間に何をしているかが伝わってくる。そういうコードは使うのが楽しいし、自分のコードもそうあるべきだと思わせてくれる。本書の目的は、君のコードを良くすることだ。（本書「はじめに」より）コードは理解しやすくなければならない。本書はこの原則を日々のコーディングの様々な場面に当てはめる方法を紹介します。名前の付け方、コメントの書き方など表面上の改善について。コードを動かすための制御フロー、論理式、変数などループとロジックについて。またコードを再構成するための方法。さらにテストの書き方などについて、楽しいイラストと共に説明しています。日本語版ではRubyやgroongaのコミッタとしても著名な須藤功平氏による解説を収録。ここで紹介する正誤表には、書籍発行後に気づいた誤植や更新された情報を掲載しています。以下のリストに記載の年月は、正誤表を作成し、増刷書籍を印刷した月です。お手持ちの書籍では、すでに修正が施されている場合がありますので、書籍最終ページの奥付でお手持ちの書籍の刷版、刷り年月日をご確認の上、ご利用ください。誤： for (Node node = list-head; node != NULL; node = node-next) Print(node-data); ↓ 正： for (Node* node = list->head; node != NULL; node = node->next) Print(node->data);

https://www.oreilly.co.jp/books/9784873115658/

Memo

はじめに

本書の目的

💡

本書の目的は、読みやすいコードを書くことである。その中心となるのは、コードは理解しやすくなければいけないという考えだ。 (px)

1. 理解しやすいコード

読みやすさの基本定理

💡

コードは他の人が最短時間で理解できるように書かなければいけない。 (p3)

2. 名前に情報を詰め込む

💡

名前をつけるときには、それが変数であっても、関数であっても、クラスであっても、同じ原則を当てはめることができる。名前は短いコメントだと思えばいい。短くてもいい名前をつければ、それだけ多くの情報を伝えることができる。 (p10)

あいまい単語の代替案

あいまいな単語は明確にしよう(p12)

単語	代替案
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

イテレータが複数あるとき

💡

イテレータが複数あるときは、i,j,kではなく、club_i,member_i,users_i とすればよい。 (p15)

無理に1つにまとめない

💡

直交する概念は無理に1つにまとめるのではなく、別々に使えるようにするとよい。(P18) ex) —run_locally → —extra_logging, —use_local_database (p18)

値の単位は変数名に入れる

💡

ex) delay → delayMs (p20)

その他の重要な属性を追加する

💡

危険や注意を喚起する情報がある場合は、変数名に追加した方がいい。 ex ) password → plaintext_password (処理をする前に暗号化すべきであることがわかる) (p21)

スコープが小さければ短い名前でもいい

💡

スコープが小さければ短い名前でもいい。すべての情報がそのスコープで全部みえるから。 (p23)

不要な単語を投げ捨てる。

💡

ex) convertToString() → toString(), doServeLoop() → serveLoop() (p24)

3. 誤解されない名前

💡

ex) Clip(text, length) - 最後からlength 文字を削除する(remove) - 最大length文字まで切り詰める(truncate) ※文字数を意味しているので、引数もmax_length → max_chars

💡

限界値を明確にするには、名前の前にmaxやminをつけよう (p32)

💡

範囲を指定するときはfirstとlastを使う (p32)

💡

包含/排他的範囲にはbeginとendを使う (p33)

4. 美しさ

縦の線をまっすぐにする

💡

縦の線をまっすぐにすれば、文章に目を通し安くなる。列を整列させれば、コードが読みやすくなることがある。縦の線が「視覚的な手すり」になれば、流し見ができるようになる。これは「似ているコードは似ているように見せる」のいい例だ。 (p48)

コードを「段落」に分割する

💡

- 似ている考えをグループにまとめて、他の考えと分けるためだ。 - 視覚的な「踏み石」を提供できるからだ。これがなければ、ページのなかで自分の場所を見失ってしまう。 - 段落単位で移動できるようになるからだ。 - 段落ごとに要約コメントを追加する。 (p51)

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

💡

コードからすぐにわかることをコメントに書かない。 (p58)

💡

ひどい名前はコメントをつけずに名前を変える。関数名はいろんなところで使用されるのだから、優れたコメントよりも名前のほうが大切。 (p59)

💡

優れたコメントというのは「考えを記録する」ためのものである。コードを書いているときに持っている「大切な考え」のことだ。監督のコメンタリーみたいなもの。 (p60)

💡

定数を定義するときには、なぜその値を持っているのかという「背景」をコメントする。 (p62)

💡

読み手の立場になって考える。プロジェクトのことを君のように熟知していない人が質問しそうなことを想像する。 (p63)

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

💡

コメントは領域に対する情報の比率が高くなければいけない。 (p72)

💡

コメントは簡潔にする (p72)

💡

あいまいな代名詞を避ける。 ex)これ、それ (p73)

歯切れの悪い文書を磨く

💡

×：これまでにクロールしたURLかどうかによって優先度を変える ○：これまでにクロールしていないURLの優先度を高くする (p73)

関数の動作を正確に記述する

💡

×：このファイルに含まれる行数を返す ○：このファイルに含まれる改行文字('\n')を数える (p74)

入出力のコーナーケースに実例を使う

💡

String Strip(String src, String chars)

×：'src' の先頭や末尾にある'chars'を除去する ○：実例：String("abba/a/ba", "ab")は"/a/"を返す

コードの意図を書く

💡

String Strip(String src, String chars)

×：listを逆順にイテレートする ○：値段の高い順に表示する

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

4行のコメントよりも、キャッシュであるみたいなことを記述する。みたいな