今度の派遣先で担当することになったプロジェクト。相変わらず、MFC なんだけど。
テストしていると、仕様書の記述と違うところがあった。調べてみると、昔のバージョンでも発生する。
過去のテスト仕様書を調べてみると、今までテストした形跡がない。潜在バグだ。
まぁ、発生するケースとしては、操作の途中で装置の電源を切ったり、ケーブルを引っこ抜いたり、中継器の電源を切ったり、おおよそ発生することのない、レア ケースだ。長い稼働期間中、クレームもあがって無いことから、実際には発生しなかったと思われる。発生していても、実際とメッセージが食い違っている程度なので、大きな問題でもない。
しかし、バグはバグだ。退治することになった。（「無駄に高品質」かもしれない）
んで、どっこ直そっかなぁ・・・と追いかけていて、ぶっ飛んだ。。。
for (;;)
{
DialogResult result = 設定ダイアログを表示();
if (result == DialogResult.No) { return; }
準備をする;
result = 確認ダイアログを表示();
if (result == DialogResult.Yes) { break; }
// No の時は設定画面に戻る
}
設定を行う;
泣きたいのは for 文じゃなく、こんなの保守するオレだぁぁぁぁぁ！！
確かに、仕様通りの動きをする。テストもされているし、仕様を満足するという品質は達成されている。
でもね。どうよ？この書き方？
確かに、一連の処理中に、モーダル ダイアログを2回出したい。でも、モーダル ダイアログからモーダル ダイアログを表示すると、ASSERT が発生する。だからといって、この書き方はどうよ？
goto 文を使いたくなかったのかもしれない。でも、for 文だからいいってモンじゃないでしょ、これ？ああ、そうか。だから、これより後に作ってあるあのプロジェクトでは、goto 文使ってんだ、必要以上に。。。
んじゃ、どう直そう？この書き方。
// goto は使わない版
do {
if (設定ダイアログを表示() == DialogResult.No) {
return;
}
準備をする;
} while (確認ダイアログを表示() == DialogResult.No);
設定を行う;
do - while ループを使い、while の試験でループが継続するのは「確認でキャンセルされたとき」ということを明確化した。少なくとも、「// No の時は設定画面に戻る」などというコメントは不要で、何をしているかわかりやすくなったと思う。
// goto 使ってもいいやん版
PrepareSetting: {
if (設定ダイアログを表示() == DialogResult.No) {
return;
}
準備をする;
}
if (確認ダイアログを表示() == DialogResult.No) {
goto PrepareSetting;
}
設定を行う;
設定準備をブレースで囲んで、どこからどの範囲を戻るのか、明示してみた。do- while でええやん、って気もする。
投稿日時 : 2007年5月22日 22:47