큰 부울 표현식이 동일한 표현식이 술어 메소드로 분류 된 것보다 더 읽기 쉽습니다? [닫은]

이해하기 쉬운 것, 큰 부울 명령문 (quite complex) 또는 동일한 명령문을 술어 메소드 (세분화 할 추가 코드)로 분류 한 것입니까?

옵션 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;
    }

메서드 이름을 주석으로 볼 수 있기 때문에 두 번째 방법을 선호하지만 코드의 기능을 이해하기 위해 모든 메서드를 읽어야하므로 코드의 의도를 추상화하기 때문에 문제가 있음을 이해합니다.

이해하기 쉬운 것

후자의 접근법. 이해하기 쉬울뿐만 아니라 작성, 테스트, 리팩토링 및 확장도 더 쉽습니다. 각각의 필수 조건은 안전하게 분리되고 자체 방식으로 처리 될 수 있습니다.

코드를 이해하기 위해 모든 메소드를 읽어야하기 때문에 문제가됩니다

메소드의 이름이 올바르게 지정 되어도 문제가되지 않습니다. 실제로 메소드 이름이 조건의 의도를 설명하므로 이해하기가 더 쉬울 것입니다.
구경꾼 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. 즉시 눈에 띄는 한 hasNoSecondaryFilter가지는 부정 HasValue속성 matchesSecondaryFilter에 논리 AND 를 사용하는 반면 부정 부정에 논리 AND 를 사용 한다는 것입니다. HasValue따라서 정반대가 아닙니다.

일반적으로 후자가 바람직하다.

통화 사이트를보다 재사용 가능하게 만듭니다. DRY를 지원합니다 (기준이 변경 될 때 변경할 장소가 적고보다 안정적으로 수행 할 수 있음). 그리고 종종 이러한 하위 기준은 다른 곳에서 독립적으로 재사용되어 그렇게 할 수 있습니다.

아, 그리고 이것들은 단위 테스트가 훨씬 쉬워 져서 올바르게 수행했다는 확신을줍니다.

이 두 가지 선택 사이에 있다면 후자가 더 좋습니다. 그러나 이것이 유일한 선택은 아닙니다! 단일 함수를 여러 if로 나누는 것은 어떻습니까? 단일 라인 테스트에서 "단락"을 대략적으로 모방하여 추가 테스트를 피하기 위해 기능을 종료하는 방법을 테스트하십시오.

읽기가 더 쉽습니다 (예를 들어 논리를 다시 확인해야 할 수도 있지만 개념은 적용됩니다).

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를 더 좋아하지만 하나의 구조적 변화를 제안합니다. 조건부 마지막 줄의 두 검사를 단일 통화로 결합합니다.

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);
}

내가 이것을 제안하는 이유는 두 가지 검사가 단일 기능 단위이고 조건부로 중첩 괄호는 오류가 발생하기 쉽다는 것입니다. 코드를 처음 작성하는 관점과 그것을 읽는 사람의 관점에서. 표현식의 하위 요소가 동일한 패턴을 따르지 않는 경우에 특히 그렇습니다.

MatchesSecondaryFilterIfPresent()조합에 가장 적합한 이름 인지 확실하지 않습니다 . 그러나 더 좋은 것은 즉시 떠오르지 않습니다.

C #에서는 코드가 객체 지향적이지 않습니다. 정적 메소드를 사용하고 있으며 정적 필드처럼 보입니다 (예 :) repo. 정적은 일반적으로 코드를 리팩토링하기 어렵고 테스트하기가 어렵고 재사용 가능성을 저해하며, 질문에 따르면 정적 사용은 객체 지향 구조보다 읽기 쉽고 유지 관리가 쉽지 않습니다.

이 코드를보다 객체 지향 형태로 변환해야합니다. 그렇게 할 때 객체, 필드 등을 비교하는 코드를 넣을만한 합리적인 장소가 있다는 것을 알게 될 것입니다. 그러면 객체를 스스로 비교하도록 요청할 수 있습니다. 그러면 큰 if 문이 간단한 비교 요청 (예 : if ( a.compareTo (b) ) { }모든 필드 비교가 포함될 수 있음)

C #에는 개체와 해당 필드를 비교할 수있는 다양한 인터페이스와 시스템 유틸리티가 있습니다. 명백한 넘어 .Equals방법, 우선, 조사 IEqualityComparer, IEquatable및 유틸리티 등 System.Collections.Generic.EqualityComparer.Default.

후자는 확실히 선호되며, 첫 번째 방법으로 사례를 보았으며 거의 ​​항상 읽을 수 없습니다. 나는 첫 번째 방법으로 실수를 저지르고 술어를 술어로 변경하라는 요청을 받았습니다.

가독성을 위해 공백을 추가하고 독자가 더 모호한 부분을 읽는 데 도움이되는 의견을 추가하면 두 가지가 거의 동일하다고 말할 수 있습니다.

기억하십시오 : 좋은 주석은 독자 가 코드를 작성할 때 생각 했던 것을 알려줍니다 .

내가 제안한 것과 같은 변화로, 나는 덜 어수선하고 분산되어 있기 때문에 아마도 이전의 접근법과 함께 갈 것입니다. 서브 루틴 호출은 각주와 같습니다. 유용한 정보를 제공하지만 읽기 흐름을 방해합니다. 술어가 더 복잡하다면, 그것들을 구체화 한 개념을 이해할 수있는 덩어리로 만들 수 있도록 별도의 방법으로 나눌 것입니다.

재사용하고 싶은 부분이 있다면, 적절하게 명명 된 기능으로 분리하는 것이 가장 좋습니다.
재사용하지 않아도 조건을보다 잘 구성하고 의미를 나타내는 레이블을 제공 할 수 있습니다 .

이제 첫 번째 옵션을 살펴보고 들여 쓰기와 줄 바꿈이 모두 유용하지도 않고 조건부 구조도 잘 구성되지 않았 음을 인정합시다.

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);
}

첫 번째는 끔찍합니다. ||를 사용하고 있습니다 같은 줄에 두 가지가 있습니다. 그것은 코드의 버그이거나 코드를 난독 화하려는 의도입니다.

    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;
}

나는 그 해결책 중 하나를 좋아하지 않으며, 추론하기가 어렵고 읽기가 어렵습니다. 더 작은 방법을 위해 더 작은 방법으로 추상화하는 것이 항상 문제를 해결하는 것은 아닙니다.

이상적으로는 속성을 metaprogrmatically 비교할 것이라고 생각하므로 새 메서드를 정의하거나 분기마다 새 속성 집합을 비교하려는 경우가 없습니다.

나는 C #에 대해 확신하지 못하지만 자바 스크립트에서는 이와 같은 것이 훨씬 나을 것이고 적어도 MatchesDefinitionId 및 MatchesParentId를 대체 할 수 있습니다

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