3

安全であることと怖がって走ることの間には微妙な境界線があることがあります。

このコードは怖い猫のゾーンに一線を越えていますか？

DuckbillPlatypusForm dbpf = null;
if (radioButtonUseExistingPlatypus.Checked) {
    dbpf = new DuckbillPlatypusForm(DuckbillSetupUtils.DuckbillPlatypusState.Readonly, funnyMammalIDs);
} else if (radioButtonCreateNewFromExistingPlatypus.Checked) {
    dbpf = new DuckbillPlatypusForm(DuckbillSetupUtils.DuckbillPlatypusState.Template, funnyMammalIDs);
} else if (radioButtonCreateNewPlatypus.Checked) {
    dbpf = new DuckbillPlatypusForm(DuckbillSetupUtils.DuckbillPlatypusState.StartNew, funnyMammalIDs);
}
if (null != dbpf)
{
    dbpf.Show();
}

結局のところ、ラジオボタンは3つしかなく、設計時に1つがチェックされるので、dbpfがnullになることはありません。どういうわけか、設計時にすべてのラジオボタンがオフになるか、このコードを更新せずに別のラジオボタンを追加して、そのボタンが選択されない限り、どの時点で「弾丸を噛み」、そのようなリスクを受け入れるのでしょうか。

4

1 に答える 1

4

将来、別のラジオボタンが追加される可能性があるため、nullをチェックすることは私の意見では良いことです。多分あなたのチームの別の開発者（あなた自身ではない）からであり、そして多分それはかなり将来の時間です。

変数がnullの場合は、例外として処理する方がよいかもしれません。これは、コードのエラーであり、修正する必要があるためです。

編集：

コードを少し並べ替えると、例外が非常に自然になります。読みをGUIから分離するだけです。

function DuckbillSetupUtils.DuckbillPlatypusState StateFromGui()
{
  if (radioButtonUseExistingPlatypus.Checked)
    return DuckbillSetupUtils.DuckbillPlatypusState.Readonly;
  if (radioButtonCreateNewFromExistingPlatypus.Checked)
    return DuckbillSetupUtils.DuckbillPlatypusState.Template;
  if (radioButtonCreateNewPlatypus.Checked)
    return DuckbillSetupUtils.DuckbillPlatypusState.StartNew;
  else
    return DuckbillSetupUtils.DuckbillPlatypusState.Undefined;
}

new DuckbillPlatypusForm(StateFromGui(), funnyMammalIDs);

これで、コンストラクターがStateUndefinedで呼び出された場合、例外をスローできます。このように、別のラジオボタンを追加する場合は、このStateFromGui関数のみを更新する必要があり、状態をテストするための単一のポイントがあります。

于 2012-07-12T22:25:00.347 に答える