元ネタ：
「どうやってるか」ではなく「ナニをやってるか」を読み解くのなら。
私も過去に、責務毎にクラス分割されたコードを他チームからきたメンバにレクチャーした際に、「いろんなところに処理が飛んでわかりづらいですね。」「switch文で処理を分けたほうが読みやすいですね。」なんていう風にチクッといわれました。
まさに、これではまってます。。。
引き継いだプロジェクトについて、客先でイベント ログにエラーが上がっているんだけど、そのエラーがどういうときにでるのか調べて、と言われました。
エラー自体は、GetLastError で採っているそうなので、SetLastError をしているところを探せばすむ話です。grep で、SetLastError とエラー コードを探せば、該当箇所はでます。
で、それは出たんだけど。
エラー コードのうち下位1バイトが、何をやっている処理か、を表しているもんだから、さぁ大変。「どういう条件で、どのコード」を調べなきゃならなくなった。。。
で、「どうやってるか」が解りやすいコードが、並んでいるわけだ。
今欲しいのは「なにをやっているか」で、それを知るためにはコードを解析して行かなきゃいけないわけだ。
しかも、増改築が繰り替えさえたコード。バージョン管理ツールは、今回（次のプロジェクト）から適用だ！！よって、過去の修正がコメントアウトされて残っているぜ！！
いろんなケースが if 文で連結されている。このコードを出すための条件はなんだ？ってのを調べるために、ず～～っと上までコードを読み登って行かなきゃならん。
これで、本当に、オブジェクト指向より生産性が高いと思いますか？
一部 Device Driver Kit なので、ベタ C なのですが。。。もし、構造化された例外処理が使えるなら、処理コードではなく、処理をそのまま文字列としてメッセージが作れることに、気がつかれているでしょうか？例外的状況を整理し、例外クラスを使い分けることで、なんの作業をしているから一目瞭然なことは、おわかり頂けるでしょうか？
コミュニティにおける、「エラーになりました」という質問に対し、多くの場合「どういうエラーが出ましたか？」「例外の種類は？」と聞くのは、例外の種類だけでもわかれば、何をしようとしてどうなったのか、想像しやすいからなんです。
投稿日時 : 2006年11月14日 22:23