リーダブルコード 感想

# はじめに
私はエンジニアになって1年経ちます。久しぶりにリーダブルコード読みこれからの開発マインドとして基準にしていきたいなと感じたので、個人的な備忘録としてつらつら書いていきます。

自分と同じ経験年数の人たちに参考になれば幸いです

本書は第Ⅰ部～第Ⅳ部、全15章構成になっています。
15章は本書の原則に従って実際に問題を解決する内容なので割愛します。ご了承ください

# 何故読むべきか
- 自分が良いと思う ≠ 他人が良いと思うコード
　例）短いコード　≠ わかりやすいコード
- チーム全体で読むことができれば共通認識を作ることができる

# 読む前の心得　
- コードは他の人が最短時間で理解できるように書かなければならない
- 最も読みやすいコードは、何も書かれていないコードだ

# 理解しやすい名前を付ける (第2~3章)
#### 鍵となる考え
3章の冒頭で大事な鍵となる考えが記載されています。

```
名前が「他の意味と間違えられることはないかだろうか？」と何度も自問自答する
```
積極的に「誤解」を探して、最適な名前を見つけましょう。
そうすれば名前だけを見て、何をする為に存在するのかが理解できるようになると書かれてます。

他には以下のようなことが書かれていました。

- 変数名は意味が通じる単語にする
- tmpやretvalなどの汎用的な名前を避ける
- 不要な単語を捨てる
```java: 例) Date型をString型に変換するメソッド名
const date = new Date()

// Before
convertDateToString(date)

// After
dateToString(date) //上と同じ意味になるがこちらの方が短いのでより良い
```
- 動詞の意味を限定する 
動詞の意味は**限定的**な方がよりわかりやすくなる

```java: 例) 動詞の意味を限定する 
// Before: 引数に渡したリストに対して「選択する」のか「除外する」のかわからない
filterItems(list) 

// After: 引数に渡したリストに対して使われていないアイテムを「除外」して返してくれるのがわかる
excludeItems(list) 
```


# 美しいコード (第4章)
#### 美しいコードとは以下の3つに当てはまる
1. 改行位置が統一されている
2. インデントが揃っている
3. 縦の線が揃っている


```java: Before
componentUpdated() {
	this.fetchUserData([
		{id: 'foo', name: 'bar'},
		{id: 'hogeeee', name: 'bar'}
	])
}
```

```java: After
componentUpdated() {
	this.fetchUserData([
		{id: 'foo',     name: 'bar'}, //変数の位置を揃えて見やすくなった
		{id: 'hogeeee', name: 'bar'}
	])
}
```


- 一貫性のあるスタイルは「正しい」スタイルよりも大切　(正しい < 一貫性)
間違ったスタイルでコーディングしている既存のプロジェクトについては既存のスタイルを踏襲すること。


# 読みやすいコメント (第5~6章)

#### なぜコメントを読むのか
- 他の人がコードを見た時に、誤りなく素早く内容を理解するため
- 明日の自分は他人と思うこと
- 文中のコードを採用した理由を受け入れられるように書く

また心得として他に以下のようなことが書かれていました。
- コードを変更するときはコメントも変更すること
コードを変更する度にコメントの内容も変えないと乖離が生まれてしまい混乱する原因になる
- ひどい名前はコメントせず修正すること
- 質問されそうなことを想像して書くこと

- コメントは正確で簡潔に　
コメントは領域に対する情報の比率が高くなければならない
情報密度の高い言葉を使ったりして、書き方を工夫すること

#### コメントすべき箇所
- 実装中に自分が困った箇所
- 自分の考えを記録したい箇所
- ファイルやクラスの一番上
- 定義した定数
- 関数内などの段落ごとに要約コメントを入れる

```java: 要約コメント　例
public User suggestNewFriends (User user, String email_password) {
   // ユーザの友達のメールアドレスを取得する。
   ...

   // ユーザのメールアカウントからすべてのメールアドレスをインポートする。
   ...
   
   // まだ友達になっていないユーザを探す。
   ...

   // それをページに表示する
   ...
}
```

# 読みやすいロジックにする (第7~9章)
#### 論理式の並び順は変わらない値を右に書く
```java
// 見にくい
if (10 > length)

// 見やすい
if (length < 10)
```
#### if/else文を書く際はreturnする条件があれば上に持ってくることでネストを少なくする(早期retrun)
```java: 早期returnの例
public boolean checkSpell(String str) {
  if (str == null) {return false};
   
  //何らかの処理
}
```
#### 説明変数を定義して分解する
```js: Before
if line.split(':')[0].strip() == "root" { }
```

```js: After
username =  line.split(':')[0].strip();
if username == "root"  {}
```

#### 要約変数を定義して分解する
```js: Before
if (request.user_id == document.owner_id) {
  // ユーザーはこの文章を編集できる
}

if (request.user_id != document.owner_id) {
  // ユーザーはこの文章を編集できない
}
```

```js: After
const user_owns_document = (request.user_id != document.owner_id)

if(user_owns_document) {
 // ユーザーはこの文章を編集できる
}

if(!user_owns_document) {
 // ユーザーはこの文章を編集できない 
}
```
#### ド・モルガンの法則
**論理式を読みやすくするための手法 (数学Aとかでやったやつ)**

```js
!（A or B） = !A and !B
!(A and B)　= !A or !B
```
コツとしては 「!」を括弧内の式に展開し**and**と**or**を逆転させることです。
この本ではこのド・モルガンの法則が紹介されていましたが、要するに複雑なロジックをより簡単にする方法がないか探すことがコードを書くうえで重要になります

他には以下のポイントがあります
- グローバル変数は使わない、変数のスコープをできるだけ小さくする
- 1度しか使わない変数は削除する
- 行数を短くするよりも他の人が理解するのにかかる時間を短くする。

# コードのリファクタリング (第10~13章)
13章の中で大事な鍵となる考えが記載されています。
#### 最も読みやすいコードは、何も書かれていないコードだ
コードを書かない時を知ることで時間も節約できるし、コードも簡潔にすることができます。
また他には以下のことが書かれてました。

- プログラムから汎用的なコードを独立させる
またこのプロジェクトにXYZ()関数があったら便利だな〜と思ったら自分で作る。
簡単に共有できるようにディレクトリ 例) `/util`を用意する

- 読みやすいコードは何も書かないコード、不要なコードは捨てる

- ライブラリを知る　
たまに15分ぐらいライブラリを読んでみよう。
どんなことができそうか感じ取るだけで良い。
そうすれば新しいコードを書いているときに「ちょっと待てよ。これは、APIで見たような。。。」と思い出すことが出来る。

- ライブラリの再利用はなぜいいことなのか
平均的なソフトウェアエンジニアが1日に書く出荷用のコードは、10行になる。 皆から使われ生き延びてきたコードには大きな価値がある。 これがライブラリの再利用が良しとされている理由の一つである。 時間の節約にもなるし、書くコードも少なくなる。

- 解決策を言葉で説明する
説明することで書くコードが明確化される。
- 書いたプログラムを分割し、一つのブロックでは一つのタスクを行うように書く
以下はコードを分解するための手順です
    1. コードが行っている「タスク」を全て列挙する
    2. タスクをできるだけ異なる関数に分解する

- コードの処理はそれぞれ明確に領域に分ける
ある領域にいるときは、他の領域のことを考えないようにする
新しい関数を作らずともコードの可読性は改善できる

# 14章 テストで読みやすくする
14章の冒頭で大事な鍵となる考えが記載されています。
#### 他のプログラマが安心してテストの追加や変更ができるように、テストコードを読みやすくする。
テストコードを読みやすくするのは、実装のコードを読みやすくするのと同じくらい大切なこと。
テストが読みやすければ、本物のコードの動作が理解しやすくなる。
また他には以下のようなことが書かれていました。

- テストが大きくて恐ろしいものだとこのようなことが起こる
    1. 本物のコードを修正するのを恐れる
    2. 新しいコードを書いたときにテストを追加しなくなる　
        → コードが正しく動いているのか自信が持てなくなる

- 大切ではない情報を隠し、大切な詳細は目立つようにするべき
第一引数に入力値、第二引数に出力する期待値のレベルに落とし込むのがベスト

- テストの適切な入力値を選択する
コードを完全にテストする最も単純な入力値の組み合わせを選択する。
コードを検証する完璧な入力値を１つ作るのではなく、小さなテストを複数作る方が簡単で読みやすい

- テストの機能に名前を付ける
接頭辞に「Test_」を付ける。その後ろに関数名、クラス名を入れるとわかりやすい
テスト関数を分割する場合、Test_<関数名>_<状況>()という形式にする

- 後でテストを書くつもりでコードを書くとテストしやすいにコードを設計するようになる。

- 入出力テストはコード１行で記述できるようにする。

- テストが失敗したら発見しやすいようなエラーメッセージを表示


# 最後に感想など
- サンプルコードがC++、Python、JavaScript、Javaで記述されていたので事前に構文を知っておいた方がよさそう

- 変数名や関数名などの名前はとても大事。名前の定義がしっかりしていれば、コメントをなくすこともできる
- 特定の言語に関するテクニックなどはほとんどなく汎用的なコーディングの入門書になっている。
- コードは他の人が最短時間で理解できるように書かなければならないを常にマインドとして持っておくこと