【社内勉強会】「リーダブルコード」の紹介



# 0.はじめに

------------------
## 対象者
* プログラマ(C++, Python, Java, JavaScript)

------------------
## 「[リーダブルコード](https://www.oreilly.co.jp/books/9784873115658/)」とは


* 「良いコードにするためのシンプルで実践的なテクニック」が、書かれた本

* 名著、良書と言われている
[Togetter 書籍『リーダブルコード』発売後の反響つぶやきまとめ](https://togetter.com/li/332543)

* [ITエンジニアに読んでほしい！技術書2014 大賞](http://www.shoeisha.co.jp/campaign/award/2014/result)

![参考図書.jpeg](https://qiita-image-store.s3.amazonaws.com/0/37903/00fbc713-df83-6e98-4d7a-b1c9088826da.jpeg)


------------------
## 伝えたいこと


* 「リーダブルコード」から、以下の観点で事例をピックアップ
    - レビュでよく指摘する項目
    - 説明しやすい項目
* 「リーダブルコード」を読むきっかけにして欲しい。本の方が体系的で分かりやすい。書いてある内容はすべて重要。

### 注意事項
* 基本的にタイトルのみを掲載していて、サンプルコードは載せていない。完全に理解するには本を読む必要がある。
* [補足]と書かれた内容は、「リーダブルコード」に掲載されていない内容

------------------
## 「リーダブルコード」の目次

1章　理解しやすいコード

第I部　表面上の改善
2章　名前に情報を詰め込む
3章　誤解されない名前
4章　美しさ
5章　コメントすべきことを知る
6章　コメントは正確で簡潔に

第II部　ループとロジックの単純化
7章　制御フローを読みやすくする
8章　巨大な式を分割する
9章　変数と読みやすさ

※10章以降は紹介しないので、省略


------------------
# 「リーダブルコード」の紹介

------------------
## 1章 理解しやすいコード

* コードは理解しやすくなければならない。
    - コードを書く上でのいちばん大切な原則

* コードは他の人が最短期間で理解できるように書かなければならない。
     - 「読みやすさの基本定理」

* 「理解するまでにかかる時間」は、その他の目標とは全く競合しない
     - 理解しやすいコードは、優れた設計やテストのしやすさにつながることが多い。


------------------
## 2章 名前に情報を詰め込む

### 2.2 tmpやretvalなどの汎用的な名前は避ける

* retvalという名前には情報がない。変数の値を表すような名前を使おう。
* tmpという名前は、生存期間が短くて、一時的な補完が最も大切な変数にだけ使おう。

### 2.5 名前の長さを決める

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

## 2.6 名前のフォーマットで情報を伝える

* アンダースコア・ダッシュ・大文字を使って、名前に情報を詰め込むことができる。

* [補足] Javaのフォーマットは後述参照

-------
## 3章 誤解されない名前

* 名前が「他の意味と間違えられることはないだろうか？」と何度も自問自答する
* 限界値を示すときは minとmaxを使う
* 範囲を示すときは firstと lastを使う
* 包括/排他的範囲には beginと endを使う


### 補足

* 対義語に注意。startの対義語はendでなくstop。
http://webspace.jugem.jp/?eid=947


-------
### 3.6 ブール値の名前

trueとfalseの意味を明確にしなければいけない。

以下の変数は、2つの解釈の仕方がある。

```cpp
bool read_password = true;
```

* パスワードを**これから**読み取る必要がある。
* パスワードを**すでに**読み取っている

`need_password`や`user_is_authenticate`を使った方がよい。

* ブール値の変数名は、頭に`is・has・can・should`などをつけて分かりやすくすることが多い。


-------
## 4章 美しさ

３つの原則

* 読み手が慣れているパターンと一貫性のあるレイアウトを使う。
* 似ているコードは似ているように見せる
* 関連するコードをまとめてブロックする。



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

### 5.2 コメントするべきでは「ない」こと
*  コードからすぐにわかることをコメントに描かない
*  ひどい名前はコメントをつけずに名前を変える
    - 「優れたコード ＞ ひどいコード ＋ 優れたコメント」

### 5.3 自分の考えを記録する
* なぜコードが他のやり方ではなくこうなっているのか（「監督のコメンタリー」）
* 定数の値にまつわる「背景」

### [個人的見解]
ソースだけでなく、データベースのテーブル名や列名にも、背景を書いた方がよさそう。

-------
### 7.5 関数から早く返す

>関数で複数の`return`分を使ってはいけないと思っている人がいる。アホくさ。関数から早く返すことはいいことだ。むしろ望ましいときもある。
～
>関数の出口を１つにしたいというのは、何らかのクリーンアップコードを確実に実行したいからだろう。現代の言語では、こうした仕組みがより洗練された形で提供されている。

Javaだと`try...finally`がクリーンアップコードのイディオム。


#### [補足] 「関数の末尾以外の return 禁止」の発生元
[MISRA-C](https://ja.wikipedia.org/wiki/MISRA-C)という「C言語のためのソフトウェア設計標準規格」が発生元らしい。

http://d.hatena.ne.jp/eel3/20121225/1356443485



-------
## 9.2 変数のスコープを縮める
* 変数のことが見えるコード行数をできるだけ減らす。
* 定義の位置を下げる。
    - 変数の定義は変数を使う直前に移動する
    - 元々のC言語では、関数やブロックの先頭で変数を定義する必要があった。


-------
# 付録

-------
## Javaの一般的な命名ルール


* クラス名: 大文字始まりのキャメルケース
* 変数: 小文字始まりのキャメルケース
* 定数: 全て大文字で、スネークケース(アンダースコア区切り)
* パッケージ: 全て小文字
* 変数は名詞、メソッドは動詞で命名する


### 参考になるコーディング規約

* [Google Java Style Guide(非公式和訳)](https://kazurof.github.io/GoogleJavaStyle-ja/#s5-naming)


-------
## コーディング規約に関する個人的見解

* 他の言語の事情を持ち込まない
   - C言語のルールをJavaに持ち込まない
   - インデントスタイルなども含む

* 時代を意識する
    - IDEの発達により、読みやすいコードの定義が多少変わる
    - Javaは、かつてフィールドの末尾にアンダースコアをつけていた。今は、IDEで色分け表示されるので、非推奨。
    https://www.acroquest.co.jp/webworkshop/javacordingrule/Acroquest_JavaCodingStandard_7_0.pdf
    - 「リーダブルコード」の内容も、いずれは古臭くなるかもしれない


-----
## 参考サイト
http://qiita.com/AKB428/items/20e81ccc8d9998b5535d