自分メモ用
使えそうな部分を抽出しました。
名前に情報を詰め込む（２章）
・ループ変数は配列名の最初の文字と同じにするとわかりやすい
member[mi] employee[ei]
for(mi = 1; mi <= 100; mi++)
・単位があれば変数に加えるとよい
例：ミリ秒→ms キロバイト→KBなど
・変数を定義した行と使う行が近ければ短い変数名で構わない。
使うのが遠い時は長い変数名でもしっかり書く。
・最大値、最小値を表す定数の頭にはmax,minをつける
max_count;
min_password_char;
・真偽値を表す変数には頭に is.has,can,shouldをつけることが多い
美しさ（４章）
・似ているコードは似ているように見せる
例：似たようなメソッド（変数を変えただけみたいな）を複数使う時は、
イコールの後に必ず改行する。みたいに一貫性？を持たせる。
・改行や空白を駆使して、縦を揃えるように意識する
・変数の羅列などではブロックごとにコメントを入れるなど、まとまりを意識する
・いろいろ工夫はあるが、一番重要なのはプロジェクトで一貫性を持たせること
コメントすべきことを知る(５章)
・コメントはひどい名前の埋め合わせに使うものでは無い
・いい変数名 ＞ ひどい変数名 ＋ いいコメント
・定数には何故そうしたかの考えを入れる
const int max_temp = 45; //45℃以上だと熱すぎて火傷してしまう
・コードを理解するためならwhet でも how でも why でもなんでも書こう
・なぜこうなっているかを書くよに意識する
コメントは正確で簡潔に（６章）
・代名詞は避ける
例：それ、あれ
・条件分岐では具体的に書く
例：取得した値によって優先度を決める → 取得した値が正なら優先度を高くする
・コメントに実例を入れてしまう
//性、名を逆転させて、間に空白を入れる
//fullName(String “田中”,String ”太郎”)は ”太郎 田中”になる
String fullName(String lastName,String firstName){
}
・情報密度の高い言葉を使う
例：//所在地を正規化する(例：”Avenue” → “Ave.”)。
制御フローを読みやすくする（７章）
・条件文は左が変数で、右が比べられる数（定数？）
例：if( length > 10){}
「もし、あなたの年齢が１８歳以上なら」
→「もし18年があなたの年齢以下ならば」だと気持ち悪い
・条件文は肯定が策にくるようにする、単純な条件を先に書く、関心を引く条件や目立つ条件を先に書く
・do-whileはあまり使わない方が良い
巨大な指揮を分割する（８章）
・ドモルガンの法則を使って条件式を単純化した方が良い
・説明変数を使う。
→if line.split(':'[0].strip() == "root";
username = line.split(':'[0].strip();
if username == "root"
変数と読みやすさ（９章）
・変数のスコープはなるべく短くする
→変数はなるべくpublicを使う。
前章と違って逆に変数を減らすという話だったが、少し難しかった。
無関係の下位問題を抽出する（１０章）
理想系としては
function(){
functionA();
functionB();
functionC();
}
という形にすることである？
一度に一つのことを（１１章）
・ややこしい変数は最初に定義すると楽
var place = location_info["LocalityName"];
if(!place){
place = location_info["SubAdministrativeAreaNaem"];
}
if(!place){
place = location_info["AdministrativeAreaName"];
}
.
.
.
毎回出てくる place = location_info["~"]
の部分を、最初に変数として定義する
var town = lovation_info["LocalityName"];
var city = lovation_info["SubAdministrativeAreaName"];
var state = lovation_info["AdministrativeAreaName"];
var country = lovation_info["CountryName"];
「一度に一つのことを」の部分では無いが、こうするだけでだいぶスッキリする。
これがリファクタリング？
要するにひとつのメソッドに一機能？
コードに想いを込める（１２章）
複雑なプログラムの時は、一旦動きを日本語で説明してみる。
困ったらラバーダッキング。
でも人に見られないように気をつけよう。
短いコードで書く（１３章）
・コードを書いたら削除したく無いものだ。書いたコードこそ実際の仕事の証で、それを消してしまったら時間が無駄になる。
→めっちゃわかる。自分もつい先日もチーム開発で同じことをしてしまった。ちっぽけなプライドなんて捨ててプロジェクトのことを第一に考えよう。
・ライブラリを使う
平均的なエンジニアが１日にかけるコードの量は１０行らしい。
本当かよって思ったけど、デバックやらテストやらを乗り越えられるコードたちが最終的にそのくらいになるらしい。
ライブラリとは正しく使えればそれだけで何行も稼げるので、どんどん使っていこうということ。