崖っぷちの男

たぶん技術っぽいネタ。ブログ名が決められない

[書籍]CODE COMPLETEを読み中1

ちょっと間が空いてしまうので今読んでいる本についてちょっとだけ。
今、言わずと知れたこの本を読んでいます。


Code Complete第2版〈上〉―完全なプログラミングを目指して

Code Complete第2版〈上〉―完全なプログラミングを目指して


上下で35章あってかなり量が多いです。たぶんまだ半分くらいしか読んでいません。
6章についてはネットでも読めるみたいです:


@IT: BOOK Preview:Code Complete 第2版 第6章 クラスの作成

ここまでの感想など

「古いなあ」と感じます。この本の中で最新の情報、というのは2004年くらいの情報になります。もちろん今に通用しない、なんてことはないですが、そういう部分もあるだろうし、時間が過ぎるともっと古くなる部分が出てくるのかなあと思ったり。


あと論文の引用や統計がよく出てきます。こっちの方法とこっちの方法はそれぞれこれくらいのコスト、みたいな研究結果が載っています。まあ確かに何の根拠もなく書かれるよりはいいですが、その研究はちゃんとしたものなのかなあとか思ってしまったり。論文への参照があるので自分で読めってことですね。。


読み方については上下巻関係なく好きなところから読んだ方が良さそうです。量が多いので。


最後に今すぐ思い出せる印象に残っている部分を;

  • 上司から「設計はいいから開発をすすめてくれ」といわれても、そこは上司を説得してちゃんと設計しましょう

うんうんそうだよねって100回ぐらい言いたい。

  • 変数の生存時間を短くしましょうね

定義してから使い終わるまでの行数をできるだけ短くってこと。VBA やと関数の頭でまとめて初期化、とかやったりしてあまり意識したことがなかった。

  • 条件式が分かりにくかったらブール変数作ってそこに入れてその変数名で何の判断してるか表したらええやん

ブール変数ってそういう使い方あるのね。。

  • コメント完全不要論も存在する。ただ見出し程度にはつけた方がよい。コメントで説明しないといけないほど分かりづらいところはまずコードを見直しましょう。
  • 保守しにくいコメントの書き方はどうせ保守しないからやめとけ。見た目重視しすぎて修正がめんどくなるようなコーディング規約は採用すんな。綺麗だけど修正してなくて実際の仕様とずれてる設計書よりは汚なくてもちゃんと修正されてる設計書の方がいい

確かにスペースの数とかで調整するのめんどいよね。。ドキュメントも同様。「あ、修正が楽な書式にすればいいんだ」と思うと何か気持ちが晴れた。

  • 色んな言語でまとめて規約をあてはめたいなら関数名は最初大文字をおすすめ

うーむ。PHP やらよく関わる言語の規約って最初小文字が多いような。


うお!地震こわい!出勤しなきゃ。