はじめに
コードを書く時、「こういう時ってどう書いたらいいの?」「そもそも何が綺麗なコードなの?」と悩んだことはありませんか?
私はあります。
この記事はかの有名な リーダブルコード
を読んだ際、私自身が出来ていなかったこと、意識しなければならないと思ったことを纏めたものです。
自分なりに纏めていますので、おかしい記述等もあるかもしれませんが、その際はご指摘ください。
命名規則について
具体的な名前を付ける
- 誰が見ても、その名前だけで以下の2点が分かるような名前を付ける。
- 何をするメソッドか
- 何が格納されている変数か
- 以下の項目を意識すると具体的な名前になりやすい。
- 動詞を使うときは、より明確な動詞を選ぶ。汎用的なものはなるべく使わない。(類語を調べ、その中から選ぶといい)
- 私はこちらの記事を参考にするようにしています。
- 値の単位を付ける。(時間、サイズなど)
- 「どんな」を意識する。具体的にいうと形容詞や中身を連想できる名詞を添える。
-
records
よりもmessages
、 ハッシュを格納する変数であれば○○_hash
の方が直感的に中身の想像が出来る。
-
- 動詞を使うときは、より明確な動詞を選ぶ。汎用的なものはなるべく使わない。(類語を調べ、その中から選ぶといい)
リファクタリングするときに意識すること
ベースとして意識することについて
- 同じことは何度も書かない。
- 同じことを何度も書く必要がある場合はメソッドに分ける、変数に格納する
- 並び順に意味を持たせる。
- 複数変数が出てくる場合、定数が複数出てくる場合はその並びに意味を持たせる。
- 例:アルファベット順、画面での並び順、ファイルへの出力順など
- 複数変数が出てくる場合、定数が複数出てくる場合はその並びに意味を持たせる。
- 行数が多い場合は適度に改行を挟み、見やすくする。
- 例:処理のまとまり単位で改行、など。
コメントについて
書いてはいけないコメント
- コードを見れば誰でも分かること
- メソッド名や変数名について説明するようなコメント(それは付けている名前が悪い)
不具合があるコードに付けるコメント
- 以下のprefixを付ける
prefix | 意味 |
---|---|
TODO: | あとで直す |
FIXME: | 既知のバグがあるコード |
HACK: | あまり綺麗じゃない |
XXX: | 大きな問題がある |
※prefix
が大文字の場合は大きな問題、小文字の場合は小さな問題という意味合いになります。
※TODO(ラテ太郎):
みたいな書き方をします。
コメントを書いてもいい場所
- 読み手が一見で分からない or 疑問を持ちそうなところ
- なんで?これは何?と思われるようなコードであるならば、コメントの記載が必要です。
- 間違えて使われる可能性がありそうなところ
簡潔なコメントの書き方
-
その
のような指示語は避ける。(自分が思っているものと違う認識をされる可能性がある為、具体的に書くのが良いです。) -
かどうか
という表現は使わない。- どうなったらどう、という書き方を心がける
-
×: Aかどうか
○ : AならばB
- 情報密度の高い言葉を使う。
- 自分の伝えたい内容が集約された言葉を選ぶことを意識すればコメントが簡潔になります。
- 実例を書く
ループ・ロジックの単純化
条件式
- 条件は肯定が正義。(わかりやすい)
- ド・モルガンの法則を駆使してなるべく肯定的な条件になるようにする。否定の否定、は使わない。悪。
- 目立つ条件、重要な条件から書く。
- 何でもかんでも三項演算子を使わない(わかりにくくなるため)
- 早期リターンできる時は早期リターンする(早期リターンすることでネストが減る。)
まとめ
やっぱり命名って難しい!!!!!
まずは上記のような、常に付きまとってくる問題と戦いながら、可読性の高いコードを書けるようになりたいと思います。