『リーダブルコード』第１部 -表面上の改善-

こんにちは。

うっくんの日報から目が離せないですね。

さて、今日は『リーダブルコード』の第１部、表面上の改善です。

第１部は２章～６章までで、
名前の付け方、コードの美しさ、コメントについて書かかれていました。

名前の付け方（ポイント）

・明確な単語を選ぶ
getとかはふわっとしてる。
状況に合わせてFetchやDownloadなど明確な単語を使う。

・汎用的な名前を避ける
すぐに役目が終わるような変数や、
明確な理由があれば使ってもおk。

・具体的な名前を使って、物事を詳細に説明する
用語を省略すると混乱を招く。ので、変なところで省略しない。
（チームのみんながわかる省略方法だったら使っておk。）
この関数（変数）が何をするものなのかを詳細に説明した名前を付ける。

・変数名に大切な情報を追加する
ミリ秒を表す変数には後ろに_msをつけたり、
これからエスケープが必要な変数には前にraw_をつける。

・スコープの大きな変数には長い名前を付ける
謎めいた暗号のような名前を付けず、はっきりわかるような名前を付ける。
短い名前はスコープが数行の変数につける。

・大文字やアンダースコアなどに意味を含める
クラスのメンバ変数にアンダースコアを付けてローカル変数と区別したり、
定数は大文字で書いて区別したりする。

・最善の名前は、誤解されない名前。
コードを読む人が自分の意図を正しく理解できるような名前をつける。
反対意見を考えたり、友人に意見を貰って名前をつける。

美しさ

・同じようなことをしているブロックは、シルエットも同じようなものにする

・縦の線をまっすぐにする

・意味のある順番で並べ、それを一貫する

・空行を使って、大きなブロックを段落にわける

コメント

流れ

・まずは頭のなかにあるコメントをたくさん残す

・コメントを読んで改善が必要なものを見つける

・改善する

コメントするのがうまくなってくれば、修正の必要がなくなる。

コメントするべきではないことを知る

・コードから「すぐに」理解できること

・ひどいコードを補うためのコメント（コメントするのではなくコードを直す）

これらはコードが無駄に長くなってしまうのでコメントするべきではない。

コードを書いているときの自分の考えを記録

・他のやり方ではなくこのやり方を選んだ理由（監督のコメンタリー的な）

・コードの欠陥
　よく使われる記法と意味
　　TODO: あとで手を付ける
　　FIXME: 既知の不具合があるコード
　　HACK: あまりきれいじゃない解決法
　　XXX: 危険！大きな問題がある

・定数にその値を設定した背景
これらの自分の考えは消えちゃう大事な情報なので記録する。

読み手の立場になって考える

・読み手が疑問に思いそうなところを予想してコメントを書く

・全体像のコメントを書く

・コードブロックにコメントをつけて概要をまとめる

小さな領域に多くの情報を詰め込んだコメントを書く

・それやこれなどの代名詞は使わない

・関数の動作はできるだけ正確に説明する

・よくわからない引数にはインラインコメントを使う
　（例、function( /* arg = */ 20, ... )のような）

・多くの意味が詰め込まれた言葉や表現を使って、コメントを簡潔に保つ
これ苦手です。言葉を知らなすぎてつらい。。

こんな感じでしたー。

全然まとまってなくてごめんなさい。。

うーん。

課題以外の勉強をする時間と、ブログを書く時間を確保するのが難しいです。

課題で使ってる技術をブログで書くにしても、まとめるのに異常に時間がかかります。。

１日１技術の時間を確保できるように、

夜は眠いので、朝早く起きたいと思います。

7:30に会社いくかー。←