大きなブール式は、述語メソッドに分解された同じ式より読みやすいですか？[閉まっている]

理解しやすいもの、大きなブール文（非常に複雑なもの）、または述語メソッドに分解された同じ文（多くの余分なコードを読む）

オプション1、大きなブール式：

    private static bool ContextMatchesProp(CurrentSearchContext context, TValToMatch propVal)
    {

        return propVal.PropertyId == context.Definition.Id
            && !repo.ParentId.HasValue || repo.ParentId == propVal.ParentId
            && ((propVal.SecondaryFilter.HasValue && context.SecondaryFilter.HasValue && propVal.SecondaryFilter.Value == context.SecondaryFilter) || (!context.SecondaryFilter.HasValue && !propVal.SecondaryFilter.HasValue));
    }

オプション2、条件を述語メソッドに分割：

    private static bool ContextMatchesProp(CurrentSearchContext context, TValToMatch propVal)
    {
        return MatchesDefinitionId(context, propVal)
            && MatchesParentId(propVal)
            && (MatchedSecondaryFilter(context, propVal) || HasNoSecondaryFilter(context, propVal));
    }

    private static bool HasNoSecondaryFilter(CurrentSearchContext context, TValToMatch propVal)
    {
        return (!context.No.HasValue && !propVal.SecondaryFilter.HasValue);
    }

    private static bool MatchedSecondaryFilter(CurrentSearchContext context, TValToMatch propVal)
    {
        return (propVal.SecondaryFilter.HasValue && context.No.HasValue && propVal.SecondaryFilter.Value == context.No);
    }

    private bool MatchesParentId(TValToMatch propVal)
    {
        return (!repo.ParentId.HasValue || repo.ParentId == propVal.ParentId);
    }

    private static bool MatchesDefinitionId(CurrentSearchContext context, TValToMatch propVal)
    {
        return propVal.PropertyId == context.Definition.Id;
    }

メソッド名はコメントとして表示されるため、2番目のアプローチを好みますが、コードが何をするのかを理解するためにすべてのメソッドを読む必要があるため、問題があることを理解し、コードの意図を抽象化します。

理解しやすいもの

後者のアプローチ。理解しやすいだけでなく、記述、テスト、リファクタリング、拡張も簡単です。必要な各条件は、独自の方法で安全に分離および処理できます。

コードを理解するにはすべてのメソッドを読む必要があるため、問題があります

メソッドの名前が適切であれば問題ありません。実際、メソッド名は条件の意図を説明するため、理解しやすいでしょう。
見物人にとってはif MatchesDefinitionId()、if (propVal.PropertyId == context.Definition.Id)

[個人的には、最初のアプローチで目が痛む。]

これがこれらの述語関数が使用される唯一の場所である場合、bool代わりにローカル変数を使用することもできます。

private static bool ContextMatchesProp(CurrentSearchContext context, TValToMatch propVal)
{
    bool matchesDefinitionId = (propVal.PropertyId == context.Definition.Id);
    bool matchesParentId = (!repo.ParentId.HasValue || repo.ParentId == propVal.ParentId);
    bool matchesSecondaryFilter = (propVal.SecondaryFilter.HasValue && context.No.HasValue && propVal.SecondaryFilter.Value == context.No);
    bool hasNoSecondaryFilter = (!context.No.HasValue && !propVal.SecondaryFilter.HasValue);

    return matchesDefinitionId
        && matchesParentId
        && matchesSecondaryFilter || hasNoSecondaryFilter;
}

これらはさらに細分化され、読みやすくするために並べ替えられます。たとえば、

bool hasSecondaryFilter = propVal.SecondaryFilter.HasValue;

そして、すべてのインスタンスを置き換えますpropVal.SecondaryFilter.HasValue。すぐに突き出されるものの1つはhasNoSecondaryFilter、否定されたHasValueプロパティで論理AND を使用し、否定されていないプロパティでmatchesSecondaryFilter論理AND を使用するHasValueことです。したがって、正反対ではありません。

一般に、後者が好まれます。

これにより、通話サイトがより再利用可能になります。DRYをサポートしています（基準が変更されたときに変更する場所が少なく、より確実に変更できることを意味します）。そして非常に多くの場合、これらの副基準は他の場所で独立して再利用されるものであり、それを可能にします。

ああ、それはこのようなものを単体テストするのをはるかに簡単にし、あなたがそれを正しくやったという自信を与えます。

これらの2つの選択肢の間にある場合は、後者の方が優れています。ただし、これらは唯一の選択肢ではありません！単一の関数を複数のifに分割してみませんか？追加のテストを回避するために関数を終了する方法をテストし、1行のテストで「短絡」を大まかにエミュレートします。

これは読みやすいです（例のロジックを再確認する必要があるかもしれませんが、概念は当てはまります）。

private static bool ContextMatchesProp(CurrentSearchContext context, TValToMatch propVal)
{
    if( propVal.PropertyId != context.Definition.Id ) return false;

    if( repo.ParentId.HasValue || repo.ParentId != propVal.ParentId ) return false;

    if( propVal.SecondaryFilter.HasValue && 
        context.SecondaryFilter.HasValue && 
        propVal.SecondaryFilter.Value == context.SecondaryFilter ) return true;

    if( !context.SecondaryFilter.HasValue && 
        !propVal.SecondaryFilter.HasValue) return true;

    return false;   
}

私はオプション2の方が好きですが、構造的な変更を提案します。条件の最後の行の2つのチェックを1つの呼び出しに結合します。

private static bool ContextMatchesProp(CurrentSearchContext context, TValToMatch propVal)
{
    return MatchesDefinitionId(context, propVal)
        && MatchesParentId(propVal)
        && MatchesSecondaryFilterIfPresent(context, propVal);
}

private static bool MatchesSecondaryFilterIfPresent(CurrentSearchContext context, 
                                                    TValToMatch propVal)
{
    return MatchedSecondaryFilter(context, propVal) 
               || HasNoSecondaryFilter(context, propVal);
}

私がこれを提案する理由は、2つのチェックが単一の機能ユニットであり、条件文の入れ子括弧がエラーを起こしやすいということです。最初にコードを書くという観点とそれを読む人の観点の両方から。これは、式のサブ要素が同じパターンに従っていない場合に特に当てはまります。

MatchesSecondaryFilterIfPresent()組み合わせに最適な名前であるかどうかはわかりません。しかし、すぐに思い浮かぶものはありません。

C＃では、コードはあまりオブジェクト指向ではありません。静的メソッドと静的フィールドのように見えるものを使用しています（例repo）。一般的に、静的はコードのリファクタリングを困難にし、テストを困難にしますが、再利用性を妨げます。そして、あなたの質問に答えてください。

このコードをよりオブジェクト指向の形式に変換する必要があります。すると、オブジェクト、フィールドなどの比較を行うコードを配置する賢明な場所があることがわかります。それから、オブジェクトに自分自身を比較するように依頼することができます。比較する単純なリクエスト（たとえばif ( a.compareTo (b) ) { }、すべてのフィールド比較を含めることができます）

C＃には、オブジェクトとそのフィールドで比較を行うための豊富なインターフェイスとシステムユーティリティのセットがあります。明らかに超えて.Equalsの方法、スターターのために、に見てIEqualityComparer、IEquatable、およびなどのユーティリティSystem.Collections.Generic.EqualityComparer.Default。

後者の方が間違いなく好まれます。私は最初の方法で事例を見てきましたが、ほとんどの場合、読むことは不可能です。私はそれを最初の方法で行うのを間違えたので、それを述語メソッドに変更するように頼まれました。

読みやすさのために空白を追加し、より曖昧な部分を読者が理解しやすいようにコメントを追加する場合、この2つはほぼ同じだと思います。

覚えておいてください：良い解説は、コードを書いたときにあなたが考えていたことを読者に伝えます。

私が提案したような変更では、混乱が少なく拡散しているため、おそらく前者のアプローチを採用するでしょう。サブルーチン呼び出しは脚注のようなものです。有用な情報を提供しますが、読書の流れを中断します。述語がより複雑な場合は、それらを具体化する概念を理解可能なチャンクで構築できるように、それらを別々のメソッドに分割します。

まあ、再利用したい部分がある場合、それらを別々の適切な名前の関数に分けることは明らかに最善のアイデアです。
再利用しなくても、条件をより適切に構成し、その意味を説明するラベルを付けることができます。

さて、最初のオプションを見てみましょう。インデントや改行はそれほど有用ではなく、条件付きの構造化もうまくいきませんでした。

private static bool ContextMatchesProp(CurrentSearchContext context, TValToMatch propVal) {
    return propVal.PropertyId == context.Definition.Id && !repo.ParentId.HasValue
        || repo.ParentId == propVal.ParentId
        && propVal.SecondaryFilter.HasValue == context.SecondaryFilter.HasValue
        && (!propVal.SecondaryFilter.HasValue || propVal.SecondaryFilter.Value == context.SecondaryFilter.Value);
}

最初のものは絶対に恐ろしいです。||を使用しています 同じ行の2つのこと。これは、コードのバグか、コードを難読化する意図のいずれかです。

    return (   (   propVal.PropertyId == context.Definition.Id
                && !repo.ParentId.HasValue)
            || (   repo.ParentId == propVal.ParentId
                && (   (   propVal.SecondaryFilter.HasValue
                        && context.SecondaryFilter.HasValue 
                        && propVal.SecondaryFilter.Value == context.SecondaryFilter)
                    || (   !context.SecondaryFilter.HasValue
                        && !propVal.SecondaryFilter.HasValue))));

それは少なくとも半分はきちんとフォーマットされています（フォーマットが複雑な場合、それはif条件が複雑なためです）。もしフォーマットされたごみと比較して、他の何かがより良いです。しかし、あなたは極端なことしかできないようです：ifステートメントの完全な混乱、または4つの完全に無意味なメソッド。

（cond1 && cond2）|| （！cond1 && cond3）は次のように書くことができます。

cond1 ? cond2 : cond3

混乱を減らすでしょう。書きます

if (propVal.PropertyId == context.Definition.Id && !repo.ParentId.HasValue) {
    return true;
} else if (repo.ParentId != propVal.ParentId) {
    return false;
} else if (propVal.SecondaryFilter.HasValue) {
    return (   context.SecondaryFilter.HasValue
            && propVal.SecondaryFilter.Value == context.SecondaryFilter); 
} else {
    return !context.SecondaryFilter.HasValue;
}

私はこれらのソリューションのどちらも好きではありません、それらは推論するのが難しく、読むのが難しいです。小規模なメソッドのためだけに小規模なメソッドに抽象化しても、必ずしも問題が解決するとは限りません。

理想的には、プロパティをメタプログラムで比較すると思うので、新しいメソッドを定義したり、新しいプロパティのセットを比較するたびに分岐したりする必要はありません。

私はc＃についてはわかりませんが、javascriptではこのようなものははるかに優れており、少なくともMatchesDefinitionIdとMatchesParentIdを置き換えることができます

function compareContextProp(obj, property, value){
  if(obj[property])
    return obj[property] == value
  return false
}