デバッグとか

• まぁいまさらな話題でもあるがぼやきたくなったので
  • バグの中で最もいやなもののひとつは「エラーメッセージとして現れないバグ」だろう。目的の処理を行うためのプログラムを書いてコンパイルエラーも出なかった・・・しかしコンパイルエラーこそ出ていないが目的の挙動になっていない・・・などというときが一番いやなものだ。まぁ小規模なものなら見当がついたりもするが、多くのモジュールが結合しているシステムなんかになるとこれはもうデバッグ地獄だ。それまでよかった気分も最低まで落ち込める。これ、プロの現場でも結構あったりする。というか出てしまうのが普通ではないだろうか？
  • ビルゲイツはコードレビューに重きをおいている（いた？）らしい。自らやっていることもあったそうだ。これ結構やりたくないもんだが、本当だったらやっぱえらいねビルゲイツ。まぁWindows作ったのはビルゲイツではないが・・・。
    • 余談だが結構勘違いしている素人のひととかいるよな？（親父がそうだった・・・）
• コントロールポイント
  • 今はリソース管理オブジェクトが発達しているので昔に比べればリソースリークのリスクもかなりなくなったが、C/C++等を使っていると小さな関数内でリソースの確保と開放を行っているものをよく見かける。基本のあるプログラマであればスコープを抜ける際にリソースの開放は行うように気をつけているだろうが、条件分岐や関数のスコープから抜けるreturn文等が頻発する少々トリッキーなコードの中ではコントロールポイント前での処理には気をつけるべき。
    • リソースリークに限らずコントロールポイントが多数ある関数内では自分でも意図していなかった挙動に仕上がってしまっていたりすることがある。変数の値等が正しくなかったりすると頭の中では正しいロジックで書いているつもりになっており人的バグになりがち。まぁバグなんてほとんど人的なもんだといってもいいけど・・・
    • 例外処理の挙動は特にバグになりがちなようだ。
• 共通するエラー処理
  • プログラミングの先達たちの提唱するコーディングコンベンションに「コードの重複をなくす」というものがある。まぁ自分で書いててもこれはなくしたいと思うが、「共通の処理」というものはなかなか始めから洗い出せるものでもない。プログラムを書いていると、特にエラー処理なんかで共通する処理が出てくる。こういったものは早いうちに一般化を行いクラスなり関数なりにして一元管理すべき。同一の処理が散らばっているとバグの温床にもなる。