12

「ガードステートメント」パラダイムと「単一関数出口点」パラダイムを使用するプロジェクトの保守性に関する研究 (カジュアルと堅牢の両方) があるかどうか疑問に思っています。

ガード ステートメントの例 (C#):

string GetSomeString()
{
    if(necessaryConditionFails) { return null; }
    if(!FunctionWithBoolReturn(someAttribute)) { return null; }
    //all necessary conditions have been met
    //do regular processing...
    return finalStringValue;
}

単一関数の終了点の例 (C#):

string GetSomeString()
{
    string valueToReturn = null;
    if(necessaryConditionPasses && FunctionWithBoolReturn(someAttribute)) 
    { 
        //all necessary conditions have been met
        //do regular processing...
        valueToReturn = finalStringValue;
    }
    return valueToReturn;
}

両方の長所と短所が SO で際限なく議論されていることは知っていますが、各パラダイムがどれほど保守可能かについての実際の研究を探しています*。これは不明かもしれませんが、情報がそこにある場合、SOの誰かがそれがどこにあるかを知っていると思いました. これまでのところ、私の Web 検索は成功していません。

**多くのプログラマー (私を含む) が、状況に応じてコード全体で両方の原則を使用していることも認識しています。好ましいパラダイムとして使用するための優れた保守性の実績があるのはどれかを発見したいと思っています.*

4

1 に答える 1

13

単一の出口点を持つことを強制することには、いくつかの問題があります。

1 つ目は、複雑な構造につながる可能性があることです。ファイルを開き、行を読み取り、行を数値に変換し、何か問題が発生した場合にその数値またはゼロを返す必要がある関数を想像してください。単一の終了点では、ネストされた多数の if を使用することになり (ファイルが存在する場合はそれを開き、開いた場合は行を読み取り、読み取りが成功した場合は値を整数に変換します)、コードが判読できなくなります。一部は関数の最後にラベルを付けて goto を使用することで解決できます (単一の出口点と読みやすさを優先して使用したため、以前はそれを使用する必要がありました) が、理想的ではありません。

第二に、例外を使用している場合、単一の出口点が再び必要な場合は、すべてをキャッチする必要があります。

したがって、個人的には、関数の最初と実行中に多くのチェック (およびアサート) を行い、問題の最初の兆候で関数を終了することを好みます。

于 2010-02-18T22:43:05.673 に答える