リーダブルコードは "readable" であり "leadable" だ

#はじめに

　　　　あぁ、美しいコードを書きたい・・！

そんな思いで
『リーダブルコード ――より良いコードを書くためのシンプルで実践的なテクニック』
を買って読んでみた。

![リーダブルコード.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/713457/b0154f80-0e8b-2c21-34fd-18a43efd5e9c.jpeg)

読んだ感想・・。

　　　　あぁ！もっと早く読んでおけば良かった！！！

と思ってしまったが、
人間気付いた時に、あぁ今気付けて良かったと思えればそれでいいのである。
プログラマ人生は長い。まだ読んでない人は早めに読んでおくのが吉。
（とかいう私はまだまだプログラマとしてすごく浅瀬にいますｗ）

読みやすいコードを書くことで自分やチームを良い方向に導いていける。
まさに **"readable"** であり、**"leadable"** な一冊なんだと感じた。

読んだら読んだでアウトプットしたくなったので
簡単に要所を記事にしようと思って書きます。

本書は第４部（全１５章）の構成になっておりましたが第１部（１～６章）だけ書きます。
第２部以降は自分で買って読もう！！~~（書くの疲れた・・）~~

#第１部　表面上の改善

##１章　～理解しやすいコード～
#### 読みやすいとは理解しやすいということ
これは基本理念。
**他の人が見て、理解するために要する時間を少なくできるようなコード**を書こう。
そして他の人とは自分以外の誰かだけではない。
時が経てば、将来の自分も"他の人"になるのである。

#### 短ければ良いってもんじゃない
これはある程度書けるようになった人ほど陥りやすいと思う。
コード整理しすぎて後で見たら解きほぐすのに時間がかかりまくった、なんてこともよくあることだと思う。

```before.cs
Console.WriteLine(String.Format("{0}です。", xxx.IsAvailable() ? "hoge" : "fuga"));
```
よりも

```after.cs
bool status = xxx.IsAvailable();
string message = status ? "hoge" : "fuga";
Console.WriteLine(String.Format("{0}です。", message));
```
の方がコード行は多いけどパッと見て理解しやすい。ということ。
**一行で書くことがカッコイイことではないんだ！**
・・とは言え、程度問題なのでバランスは大事です。

##２章　〜名前に情報を詰め込む〜
#### 明確な単語を選ぶ
例えばウェブからデータを取得するとき
```GetData()```よりも```DownloadData()```
の方が"ウェブから"という意味が伝わりやすい。

#### 汎用的な名前を避ける
とりあえずで使ってしまいがちな、"tmp"や"retval"などの変数名を避けよう。

```before.cs
bool retval = xxx.IsAvailable();
string tmp = retval ? "hoge" : "fuga";
Console.WriteLine(String.Format("{0}です。", tmp));
```

よりも

```after.cs
bool status = xxx.IsAvailable();
string message = status ? "hoge" : "fuga";
Console.WriteLine(String.Format("{0}です。", message));
```
の方が変数の意味が伝わりやすい。
(※小さいスコープなどで、その変数の生存期間が短い場合などは除く。これも"理解しやすいかどうか"という観点から判断する。)

#### 名前に情報を追加する
例えば、テキストを取得して、それを加工して、出力する、というような処理があったとして

```before.cs
string text = GetText();                   // 取得
 ~~~ 処理A ~~~
text = String.Format("{0}です。", text);    // 加工
 ~~~ 処理B ~~~
Console.WriteLine(text);                   // 出力
```
よりも

```after.cs
string raw_text = GetText();                                    // 取得
 ~~~ 処理A ~~~
string processed_text = String.Format("{0}です。", raw_text);    // 加工
 ~~~ 処理B ~~~
Console.WriteLine(processed_text);                              // 出力
```
の方が、加工前・後の状態が伝わりやすいし、
最後の出力部分で、元のテキストを出力しようとしていた場合に
そういったバグにも気付きやすくなる。

##３章　〜誤解されない名前〜
前述の２章の内容も踏まえた上で
理解しやすいだけでなく、**見た人の誤解を生まないか**
ということも意識しよう。

例えば、配列をフィルタリングする関数があったとして、

```sample.cs
int[] Filter(int[] array, int limit_value)
{
    ~~~ 処理 ~~~
}
```
この関数名を見ただけでは
与えられた配列の中から、指定された値を限界値としてフィルタリングした値を
"取得"する関数なのか、"除外"する関数なのか誤解を生む可能性がある。

この場合、"Filter"を使うよりも
"Select"(選択)"なのか、"Exclude"(除外)"なのか、
関数名から明確に伝わるようにネーミングするのが良い。

```sample.cs
int[] Filter(int[] array, int limit_value)
{
    ~~~ 処理 ~~~
}

int[] Select(int[] array, int limit_value)
{
    ~~~ 処理 ~~~
}

int[] Exclude(int[] array, int limit_value)
{
    ~~~ 処理 ~~~
}

int[] array = { 1, 4, 9, 2, 3, 0, 6 };
var results = Filter(array, 4);          // あいまい・・
var results = Select(array, 4);          // 4以下の値を選択！
var results = Exclude(array, 4);         // 4以下の値を除外！
```

また、
上記関数は関数名以外にも誤解を招く表現がある。それは仮引数の"limit_value"だ。
"limit"（限界値）と書かれている場合、
limit_value が4の時に、4を含めるのか含めないのか誤解してしまう可能性がある。
"limit"（限界値）ではなく、"max"（最大値）であれば、4は含めるのだなとはっきりと伝わる。

正直、「そんなに全部を気にするの無理だよぉぉぉ！！！」と思ってしまうが、
気にし続けて書いていれば、そのうち無意識にネーミングできるようになっていくのだと思う。

##４章　～美しさ～
ここに関してはもう
「**コードはキレイに書こうぜ！！**」という単純な問題である。

####一貫性のあるレイアウト
改行位置やスコープの波括弧の書き方、代入部分のイコールの縦の位置を合わせる
などなど、人間が見やすいように工夫しよう！
まぁ実際はエディタのコード整形とかあるからそこまで気にしなくても大丈夫だと思う。

```dirty.cs
void XXX(){
    int first = hoge.GetValue();
    int second = fuga.GetValue();
    int third = piyo.GetValue();
}

int YYY(int value1,int value2 )
{
    return value1*value2;
}
```

```beautiful.cs
void XXX()
{
    int first  = hoge.GetValue();
    int second = fuga.GetValue();
    int third  = piyo.GetValue();
}

int YYY(int value1, int value2)
{
    return value1 * value2;
}
```

#### 郷に入っては郷に従え
一貫性を持ってキレイに書こう！とは言ったが、
「スコープの波括弧は次の行に書くのがマイルールだぜ！」と、
どんな状況でもそれを貫くのは良くない。

自分が後から参加したプロジェクトチームのソースコードが
あるルールで進んでいるのであれば、そのルールに従って書いていくのが良い。
チームとしての一貫性を守ろう。臨機応変にやっていこう！！

##５章　～コメントすべきことを知る～
####コメントするべきでは「ない」こと
基本的にソースコードを見て、
**容易に理解できるものをコメントで書く必要はない**ということ。
例えば、下記のようなコメントはコードで書いてあることを
**そのままコメントでも書いているだけ**になってしまっている。

```sample.cs
class Sample
{
    public string Name { get; set; }    // Nameプロパティ

    // コンストラクタ
    public Sample()
    {
        ~~~ 省略 ~~~
    }
}
```

####自分の考えを記録する
コードを書いている時に自分が考えていたことをコメントとして残す。
ソースコードの意図を伝えることができるし、なぜ今のコードに至っているのかが明確になる。

```sample.cs
class Person
{
    // 各人をデータベースに登録して管理するのでIDが必要。
    public Person(int id)
    {
        const int max_name_length = 100;     // 100文字を超える名前の人はそういないのでこの値にした。
        public string Name { get; set; }
        // ※Name以外にも、Ageが必要かもしれない。
    }
}
```
こんな感じでソース上にコメント書いていいの？と感じる人もいるかもしれないが
**理解するために必要な情報**であればドンドン書いて良し！
後で不要になったら、その時は消せば良いだけの話だし、
コメントを消しても実動作に影響はないのだから書けばよいのである。

##６章　～コメントは正確で簡潔に～

####曖昧さを避け、情報を正確に伝える
ある処理のコメントで
*`名前リストを受け取りファイルに書き出す。ただし、そのサイズはチェックする。`*
というコメントがあったとする。
この場合、サイズチェックするのは名前リストなのか、ファイルなのかわからない。

*`名前リストを受け取り、リストのサイズをチェックし、ファイルに書き出す。`*
とした方が、正確に伝わる。
「その」とか「この」などの代名詞も誤解を生みやすいので、なるべく避けるようにする。

#おわりに

すごく簡単に書いてきましたが、第１章の部分だけ見ても
**今よりももっと良いコード書けそう！**と思えてきませんか？？

実際は、具体例などももっと豊富でわかりやすく解説されてるので是非。
第２章以降も違った観点からのアプローチで勉強になります。

これを読んで、プロジェクトを成功に導きましょう！

この記事が"readable"になってるかだいぶ怪しいですがw
読んでいただいた方ありがとうございます。^^