たまには技術的な本を。

初心者なりに読んだ備忘録でしか無いので、既にプログラマの方にも、全くわからない方にも、面白くないようなすごい中途半端な内容になると思います＾＾；悪しからず。。。

そもそもコードは、マジメに作るならなら「とりあえず書いたらそれっきり」というものは少なそうです。というのも、テストで何かミスがあったら適宜修正する必要があるし、新しく何かを作るときにも過去のモノを流用できるならそのほうがコストがかからないから。 また、先の「２０００年問題」も、当時の開発者たちは自分の作ったプログラムがそんなに長いこと使われると想定していなかったために起きたものだと聞いています。

良いコードを書くことは、他人（半年後の忘れてる自分も含む）が読みやすいようにするということで、読みやすければそれだけ自分の作品が長持ちし、将来のコスト削減にもつながります。

個々のテクニックを箇条書きで。

命名には意味を込める。（メソッドや変数名）

• 汎用的な単語よりも、動作が具体的な単語を選ぶ（例：getやmakeは抽象的すぎる）
• 逆に汎用的な単語を使うときは、「一時的なもの」「それ以上の説明が不要なもの」のとき（例：tmpやi）
• イテレータを複数使うときは、それぞれ何に使われているかわかるようにする。
• 単位をはっきりさせる（例：時間（ミリ秒）→t_ms）

コメントはコードから読み取りにくいものを

• まずはコードを直せないか考える（優れたコード　＞　見にくいコード　＋　優れたコメント）
• メソッドのそもそも行いたい処理やを書く
• 試行の結果を書く（なぜこうなったのか明らかにするためと、他人が同じ試行をするムダを省くため）
• 他人が気になるだろうな、と思うところはとりあえず書いてみる。
• 後で直すべきところ、もっと簡潔に書けそうなところにはメモを残しておく。（修正ポイントが明確になるため）

条件分岐

• 否定より肯定でまとめる。（統一した方がみやすい）
• 単純な条件を先に（思考をすっきりさせるため）
• 目立つ条件を先に（目立つ方に意識が行きがちなため）
• do while〜や三項演算子は避ける（そもそも直感的な考え方でないため。他の一般的な手法で代用できるため）
• 何層にもネストはしない。（人がスタックできるのはせいぜい３つか４つのコトまで。それ以上は追えない→ヌケモレが起こりやすい、修正したくない）

その他

• １つのメソッドは２０行までが目安（それ以上長くなる時は分割できないか考えるべき）
• 細かい関数をたくさん作ると再利用ができる（ただし細かくし過ぎるとややこしくなる）
• 標準ライブラリの中身を知っておくべき（わざわざ自分で用意するエンジニアが多いが、正直時間のムダ）
• 一般的なエンジニアが一日に書くコード数の平均は１０行（ほとんどが再利用やテスト。そのため綺麗なコードは重要）
• 頭がいいコードには気をつける（自分が理解できるのはずっとそのことを考えていたから。初見の人にもわかるコードが良いコード。）
• 逆から考えなおすことがいい場合も（○○と××を含む、よりも△△以外、とする方がわかりやすかったり）
• 変数はなるべく不変にする。（理解しやすい）
• スコープをなるべく狭く（保守性のためにも、人のスタックの限界のためにも。）
• なるべく結合を弱く（テストが楽。予期せぬ動作が起こりにくい）

まとめ

良いコードを書くということは文章を書くのに似てます。相手の理解度を慮って、簡潔に伝えたいことを伝えることだから。 僕はプログラミング大好きなギークでは無いので、ただコーディングすること自体に興味はありません。

• そもそもなぜ作るのか？
• どうやったら効率良くなるのか？
• 相手に理解してもらうにはどうしたらいいのか？ を考えることの方が好きです。

この本の内容を意識して、相手に伝わる文章を書く練習としてコードを書いて行きたいと思います。