期待するコードを期待するように書こうという本

リーダブルコード読んだ。期待するコードを期待するように書こうという本。O’Reilly Japan – リーダブルコード

ヴィジュアル大切って言い切っててハテナマーク出てしまったけど繰り返し言われたらそんな気もしてきた。IDEリーダブルだけ考えがちだった。ファーストビュー的にぱっと見える視覚情報重要。上見たり下見たりはダルい。あと横道ではレビュアブルコードってのもあるかなーって思った。

レビュアブルコード

今の自分のお仕事のコード意味ある単位でコミットしてない。 vcsの泣き言はあるけど、問題を一対一で解決して行かないとすぐ解んなくなってしまう。svn extermal無双でgit-svnが無理ゲーになってしまい生svn触らないといけない。gitでローカルにコミットするほど細かくはないけど、local-remoteでpush できるなら今の3commitが1pushになりそうなぐらいの粒度。あれ他人が読まされても厳しいと思う。レビューツール側で何とか巻き取ればいいのかね。横道終わり。

見た目から始まって、イディオムに従って、期待に反さず、直感的で、誤解を生まないコードの具体例。汚くて本質と関係ないところは括りだしましょう。くくりだしすぎても今度は読めません。英語的に読み下せるコード、でもないですよ。

以下読みながら書いたメモ書き。本と照らし合わせないと意味不明。

indexの添字

i, j, k
member mi
user ui
これよみ辛くね
for入れ子まみれのメソッドの方を直したい

誤解を招かない命名

filter()
Clip(text, length)
min, max
first, last
begin, end

定数にコメントを付ける
なぜその値を持っているのか
これだ!

条件式の引数の並び順

ヨーダ記法見たらリーダブルコード読んでない認定していい
2変数の比較って小<大が見やすいんだけどオレだけらしい
bytes_received < bytes_expected
変化する値を左に、より安定した値を右に配置する

ネストを浅くする

“精神的スタック”

“反対から問題を解決してみる”
いい言葉だ

クラスのメンバへのアクセスを制限するもう一つの方法は、メソッドを出来るだけ
static にすることだ

えええー とはいえ前からstaticおじさんのアンチテーゼとして全部objectおじさんなことは自覚してるので正しく使いたいなあ。結局状態持ちたいんじゃね?持たざるをえないんじゃね?とは思ってる。

for で条件にtrueは混乱招くだろー
オブジェクト変わっちゃうメソッドチェーンはevilだとおもう
goosかxutpで読んだやつ

身近なライブラリに親しむ
道具箱に入れる

getは多くの人にとって軽量アクセサを意味する
へー