codeseek
TOP
.NETサンプルの解説
プログラミング考
codeseekBlog 
勉強会
ダウンロード
リンク
プロフィール
お読みください











累計:
本日
昨日



mail

・目的の実現を中心としたコード


目的の実現を中心とした記述を行うときれいなコードになります。
目的外の状態になったらそのコードブロックを抜けだすように書くことできれいなコードにすることができます、とも言い換えられます。

この場合の「目的」という言葉が指すもには、ユーザの業務ロジック自身、クラスやメソッドの責務、ハードウェアの制御、ウィンドウの制御、見栄えの制御など、よくあるサブルーチンを作る理由のすべてとほぼ同じです。
でも、サブルーチンをつくることとは大きく違います。サブルーチンを作るということは、1つにしたままでも動作をするコード群を1段階以上小さい意味のある単位に分離することを指しますが、私がここで書いている目的の実現を中心としたコードの書き方は、目的外の状態になった時点でそのコードブロックを抜けることを言っています。このためのコードにはReturnやBreakを使うことになります。

では、目的の実現を中心とした記述とは具体的にどういうものなのか、以下のサンプルをみてみてください。


・よく見かける書き方

if(nResult == Ok) {
  MessageWrite("正常");
  return;
} else if(nResult == Error) {
  MessageWrite("エラー");
  return;
}


・目的の実現を中心とした記述
if(nResult == Error) {
  MessageWrite("エラー");
  return;
}
MessageWrite("正常");
return Ok;

違いが分かりにくいのですが、上のコードでは正常時の処理を先にやってreturnしているのに対して、下のコードでは異常な状態を見つけ次第returnしてしまっています。
これらの書き方は、どちらもありふれたものなのですが、この2つの書き方はどのような違いがあるのか、深く考えたことがありますか。
上のものと下のものの違いは、下のコードでは、目的外の状態になったらさっさと処理から排除すべきだという意図をもったものになっているということです。
目的外の状態になったら処理からはずれる、それだけのことで、処理が整理された一本調子のものになり、結果的に読みやすくなっていませんか。

よく、他人が作ったプログラムの解析をせざるを得なくなった状況の人たちのほとんどが、コードが汚くて解析が進まないということを言っています。彼らを悩ませているコードはどうしてそんなに読みづらくなったのか。それはたぶん、目的をはっきりさせていないコードの書き方がされているからなのではないかと思います。

目的をはっきりさせるために、目的外の状態になったら処理から抜けるように記述しましょう。
それだけで驚くほど読みやすいコードになることでしょう。



ただ、この書き方にも問題はあります。
正常、異常の論理的レベルを同一層とした業務ロジックを実現しようという場合、下のコードの書き方では、正常のコードよりも異常の部分のコードが、論理レベルで1階層深くなってしまっていることです。これを気持ち悪いと感じるのも正常な感覚だと思います。どちらを採用するかを決めるのはおまかせします。
私は下のコードにしときますね。