へい、豚野郎です。
最近、「Qiitaの更新がないですね」と言われますが、僕にも僕にも事情があるのだ（適当）。
と、いうわけで書いてない間に何をしていたかというと、
「リーダブルコード」という本を読んでいました。
専門学校時代、先生とか「この本は素晴らしい本だ！」って言ってた（気がする）ので
買って読んだのですが、PHPerの僕にはちょっとわからない（言い訳）なところもあり
解読に時間がかかってしまいました。
それがQiitaを放置していた原因です（言い訳）。
ただ、未だにわかっていないところもあるので
それは今後のエンジニアとしての経験で補っていつかわかる日が来る様にします。
そのため、「ざっくり解説」です。
詳しい内容は是非、買って読んでください。
1. コードは読みやすく・理解しやすく
【ポイント】
・バグが見つけやすくなる。
・自分のコードが流用される可能性がある。
・他の人がわかるようにするため。
・他の人が理解する時間を短くする。
2. 名前の情報はわかりやすく
【ポイント】
・明確な単語を使う。
・汎用的な名前は避ける。
・具体的にわかるようにする。
・接尾辞・接頭辞をつけるとよい。
・文字の長さを決める。
・名前のフォーマットで情報を伝える。
変数の意味を間違えると、読み手の誤認に繋がります。
get・size・clipなど、読み手によって受け取り方が変わるので注意が必要です。
3. 美しいコード設計
【ポイント】
・読み手が慣れているパターンと一貫性のあるレイアウトを使う。
・似ているコードは似ている様に見せる。
・関連するコードはまとめてブロックにする。
読み手の読む時間が短くなります。
4. コメント
【ポイント】
・見ればわかることはコメントしない。
例. ○○を設定する。
・汚い関数名をつけてコメントするくらいなら、関数名を直す。
・自分の考えを記録する。
・コードの欠陥には恥ずかしがらずにコメントを付ける。
・意図を書く。
プロジェクトに配属されたばかりの人など、読み手はプロジェクトを熟知していません。
優れたコメントより、優れたコードを書きましょう。
5. 制御フローとループ
【ポイント】
・If文は以下の場合、
①. if( ○ > ○)
②. if( ○ < ○)
左が調査対象で、右が比較対象にした方がわかりやすい。
if()の括弧の中は否定形(!)より肯定型を使った方がよい。
・? a : bの様に省略形はわかりにくいので、普通に書いた方が読み易い。
・do/whileやgotoはあまり使わない方がよい。
6. コードを読みやすくする
【ポイント】
・無駄な変数は削除する。
・グローバル変数はあまり使わなければ避ける。
・定数は使う直前に書く。
変数の中身をあまり何度も変更しないとよいです。
7. 汎用的なコードは関数でまとめた方がよい
【ポイント】
・テストしやすくなる
・プロジェクトから独立したプログラムはUtilなどの名前で分けるとよい。
汎用的なコードは関数でまとめた方がよいが、ケースバイケースです。
やりすぎには注意してください。
8. 言葉で簡潔に説明できるコードにする
9. プロジェクトが成長すれば、コード量も増える
【ポイント】
・いらないコードは消し、重複コードを減らす。
・軽量化に機敏になる。
10. テスト
【ポイント】
・どういう振る舞いから、どういう動きを期待するか。
・丁寧にやりたければ1機能に1テスト。
・テスト名にtest1、test2などNG。
内容がわかるようにする。
・やりすぎてテストコードだらけで、本物のコードがわからなくなることに注意する。
・テストコードはなるべく簡潔に書く。
感想
さすが専門学校の先生・技術力の高かった生徒が勧めた内容だなぁと思いました。
仕事でも見たことあるものも見られました。
学生さんから現役エンジニアまで勧められる1冊です。