밥 삼촌의 Clean Code 원칙을 준수하기 위해 if-else if 문을 편집하려면 어떻게해야합니까?

밥 삼촌의 깨끗한 코드 제안을 따르고 특히 방법을 짧게 유지하려고합니다.

그래도이 논리를 단축 할 수는 없습니다.

if (checkCondition()) {addAlert(1);}
else if (checkCondition2()) {addAlert(2);}
else if (checkCondition3()) {addAlert(3);}
else if (checkCondition4()) {addAlert(4);}

나는 else를 제거 할 수 없으므로 전체를 더 작은 비트로 분리하여 "else if"의 "else"가 성능을 향상시키는 데 도움이됩니다. 이러한 조건을 평가하는 것은 비용이 많이 들고 아래 조건을 평가하지 않으면 첫 번째 조건 중 하나를 유발합니다 사실, 나는 그들을 피하고 싶습니다.

의미 적으로 말해서 이전 조건이 충족되면 다음 조건을 평가하는 것은 비즈니스 관점에서 의미가 없습니다.

편집 :이 질문은 if (if else)를 처리하는 우아한 방법 의 가능한 복제물로 식별되었습니다 .

나는 이것이 다른 질문이라고 생각합니다 (당신은 또한 그 질문들에 대한 답변을 비교함으로써 그것을 볼 수 있습니다).

• 내 질문은 첫 번째 수락 조건이 빨리 끝나는 지 확인하는 것 입니다.
• 관련 질문은 무언가를하기 위해 모든 조건을 수용 하려고합니다 . (이 질문에 대한이 답변에서 더 낫습니다 : https://softwareengineering.stackexchange.com/a/122625/96955 )

이상적으로는 경고 코드 / 번호를 자체 방법으로 가져 오는 논리를 추출해야한다고 생각합니다. 따라서 기존 코드가 줄어 듭니다.

{
    addAlert(GetConditionCode());
}

GetConditionCode ()가 조건 확인을위한 논리를 캡슐화했습니다. 마법의 숫자보다 Enum을 사용하는 것이 좋습니다.

private AlertCode GetConditionCode() {
    if (CheckCondition1()) return AlertCode.OnFire;
    if (CheckCondition2()) return AlertCode.PlagueOfBees;
    if (CheckCondition3()) return AlertCode.Godzilla;
    if (CheckCondition4()) return AlertCode.ZombieSharkNado;
    return AlertCode.None;
}

중요한 측정은 절대 크기가 아니라 코드의 복잡성입니다. 다른 조건이 실제로 단일 함수 호출이라고 가정하면 작업이 표시된 것보다 복잡하지 않은 것처럼 코드에 아무런 문제가 없다고 말할 수 있습니다. 그것은 이미 가능한 한 간단합니다.

"단순화"하려는 시도는 실제로 문제를 복잡하게 만듭니다.

물론 다른 사람들이 제안한대로 else키워드를 a return로 대체 할 수 있지만 이는 복잡성의 변화가 아니라 스타일의 문제 일뿐입니다.

곁에:

내 일반적인 조언은 절대 깨끗한 코드 규칙에 대해 종교적 관계를 가지지 않는 것입니다. 인터넷에서 보는 대부분의 코딩 조언은 적절한 맥락에서 적용되는 경우 좋지만, 모든 곳에서 동일한 조언을 적용하면 엔트리를 얻을 수 있습니다. IOCCC . 요령은 항상 인간이 코드를 쉽게 추론 할 수 있도록 균형을 유지하는 것입니다.

너무 큰 방법을 사용하면 망하게됩니다. 너무 작은 기능을 사용하면 망하게됩니다. 삼항 표현을 피하십시오. 어디에서나 삼항식을 사용하면 망할 수 있습니다. 한 줄 함수를 요구하는 장소와 50 줄 함수를 요구하는 장소가 있음을 인식하십시오 (예, 존재합니다!). 장소가 있다는 것을 실현하는 대한 호출 if()장소가 문 것을 그에 대한 호출 ?:연산자입니다. 귀하의 처분에 따라 완전한 무기고를 사용하고 항상 가장 적합한 도구를 사용하십시오. 이 조언에 대해서도 종교적 태도를 취하지 마십시오.

이것이 주어진 경우에 대해 평범한 if..else보다 '더 나은'것인지 논란의 여지가 있습니다. 그러나 당신이 경우 원하는 뭔가를 시도하는 다른 사람이 그 일을하는 일반적인 방법이다.

조건을 객체에 넣고 해당 객체를 목록에 넣습니다.

foreach(var condition in Conditions.OrderBy(i=>i.OrderToRunIn))
{
    if(condition.EvaluatesToTrue())
    {
        addAlert(condition.Alert);
        break;
    }
}

조건에 여러 작업이 필요한 경우 미친 재귀를 수행 할 수 있습니다

void RunConditionalAction(ConditionalActionSet conditions)
{
    foreach(var condition in conditions.OrderBy(i=>i.OrderToRunIn))
    {
        if(condition.EvaluatesToTrue())
        {
            RunConditionalAction(condition);
            break;
        }
    }
}

분명히 그렇습니다. 논리 패턴이있는 경우에만 작동합니다. 슈퍼 제네릭 재귀 조건부 작업을 시도하면 객체의 설정이 원래 if 문처럼 복잡해집니다. 당신은 당신의 자신의 새로운 언어 / 프레임 워크를 발명 할 것입니다.

그러나 귀하의 예 에는 패턴 이 있습니다.

이 패턴의 일반적인 사용 사례는 유효성 검사입니다. 대신에 :

bool IsValid()
{
    if(condition1 == false)
    {
        throw new ValidationException("condition1 is wrong!");
    }
    elseif(condition2 == false)
    {
    ....

}

된다

[MustHaveCondition1]
[MustHaveCondition2]
public myObject()
{
    [MustMatchRegExCondition("xyz")]
    public string myProperty {get;set;}
    public bool IsValid()
    {
        conditions = getConditionsFromReflection()
        //loop through conditions
    }
}

return;하나의 조건이 성공한 후 사용 하면 모든 elses가 저장 됩니다. return addAlert(1)해당 메소드에 리턴 값이있는 경우 직접 수행 할 수도 있습니다 .

나는 때때로 클리너로 간주되는 구조를 보았습니다.

switch(true) {
    case cond1(): 
        statement1; break;
    case cond2():
        statement2; break;
    case cond3():
        statement3; break;
    // .. etc
}

올바른 간격의 3 차도 깔끔한 대안이 될 수 있습니다.

cond1() ? statement1 :
cond2() ? statement2 :
cond3() ? statement3 : (null);

조건과 함수를 포함하는 쌍으로 배열을 만들고 첫 번째 조건이 충족 될 때까지 반복 할 수 있다고 생각합니다. 이것은 Ewan의 첫 번째 대답과 같습니다.

@Ewan의 답변의 변형으로 다음과 같은 조건 의 체인을 만들 수 있습니다 ( "플랫 목록"대신).

abstract class Condition {
  private static final  Condition LAST = new Condition(){
     public void alertOrPropagate(DisplayInterface display){
        // do nothing;
     }
  }
  private Condition next = Last;

  public Condition setNext(Condition next){
    this.next = next;
    return this; // fluent API
  }

  public void alertOrPropagate(DisplayInterface display){
     if(isConditionMeet()){
         display.alert(getMessage());
     } else {
       next.alertOrPropagate(display);
     }
  }
  protected abstract boolean isConditionMeet();
  protected abstract String getMessage();  
}

이렇게하면 정의 된 순서로 조건을 적용 할 수 있으며 인프라 (표시된 추상 클래스)는 첫 번째 충족 후에 나머지 검사를 건너 뜁니다.

조건을 적용하는 루프에서 "스킵 (skipping)"을 구현해야하는 "플랫 목록"접근 방식보다 우수합니다.

조건 체인을 설정하기 만하면됩니다.

Condition c1 = new Condition1().setNext(
  new Condition2().setNext(
   new Condition3()
 )
);

간단한 호출로 평가를 시작하십시오.

c1.alertOrPropagate(display);

우선, 원래 코드는 끔찍한 IMO가 아닙니다. 꽤 이해하기 쉽고 본질적으로 나쁜 것은 없습니다.

그런 다음 마음에 들지 않으면 @Ewan의 아이디어를 기반으로 목록을 사용하지만 다소 부 자연스러운 foreach break패턴을 제거하십시오 .

public class conditions
{
    private List<Condition> cList;
    private int position;

    public Condition Head
    {
        get { return cList[position];}
    }

    public bool Next()
    {
        return (position++ < cList.Count);
    }
}


while not conditions.head.check() {
  conditions.next()
}
conditions.head.alert()

이제 이것을 선택한 언어로 조정하고 목록의 각 요소를 객체, 튜플 등 무엇이든 만들면 좋습니다.

편집 : 생각만큼 명확하지 않은 것처럼 보이므로 더 자세히 설명하겠습니다. conditions일종의 정렬 된 목록입니다. head현재 조사중인 요소입니다. 처음에는 목록의 첫 번째 요소이며, 매번 next()호출 될 때마다 다음 요소가됩니다. check()및 alert()있습니다 checkConditionX()및 addAlert(X)영업 이익에서.

이 질문에는 구체적인 내용이 없습니다. 조건이 다음과 같은 경우 :

• 변경 될 수 있습니다
• 응용 프로그램 또는 시스템의 다른 부분에서 반복되거나
• 특정 경우에 수정 됨 (예 : 다른 빌드, 테스트, 배포)

또는 내용 addAlert이 더 복잡한 경우 c #에서 더 나은 해결책은 다음과 같습니다.

//in some central spot
IEnumerable<Tuple<Func<bool>, int>> Conditions = new ... {
  Tuple.Create(CheckCondition1, 1),
  Tuple.Create(CheckCondition2, 2),
  ...
}

//at the original place
var matchingCondition = Conditions.Where(c=>c.Item1()).FirstOrDefault();
if(matchingCondition != null) 
  addAlert(matchingCondition.Item2)

튜플은 c # <8에서 그렇게 아름답 지 않지만 편의를 위해 선택되었습니다.

이 방법의 장점은 위의 옵션 중 어느 것도 적용되지 않더라도 구조가 정적으로 입력된다는 것입니다. 실수로를 잃어 버릴 수는 없습니다 else.

가장 좋은 방법은 줄이기 위해 복잡성을 당신이 많은이 곳의 경우를 if->then statements사용하는 것입니다 사전 또는 목록 키 값을 저장하기 위해 (종속 언어) (if 문 값 또는 일부 값) 다음 값 / 함수 결과가.

예를 들어 (C #) 대신 :

if (i > 10) { return "Two"; }
else if (i > 8) { return "Four" }
else if (i > 4) { return "Eight" }
return "Ten";  //etc etc say anything after 3 or 4 values

간단하게 할 수 있습니다

var results = new Dictionary<int, string>
{
  { 10, "Two" },
  { 8, "Four"},
  { 4, "Eight"},
  { 0, "Ten"},
}

foreach(var key in results.Keys)
{
  if (i > results[key]) return results.Values[key];
}

더 현대적인 언어를 사용하는 경우 더 많은 논리 를 저장하고 단순히 값 (c #)을 저장할 수 있습니다 . 이것은 실제로 인라인 함수 일 뿐이지 만 논리가 나쁘게 인라인으로 배치 해야하는 경우 다른 함수를 가리킬 수도 있습니다.

var results = new Dictionary<Func<int, bool>, Func<int, string>>
{
  { (i) => return i > 10; ,
    (i) => return i.ToString() },
  // etc
};

foreach(var key in results.Keys)
{ 
  if (key(i)) return results.Values[key](i);
}

밥 삼촌의 깨끗한 코드 제안을 따르고 특히 방법을 짧게 유지하려고합니다.

그래도이 논리를 단축 할 수는 없습니다.

if (checkCondition()) {addAlert(1);}
else if (checkCondition2()) {addAlert(2);}
else if (checkCondition3()) {addAlert(3);}
else if (checkCondition4()) {addAlert(4);}

코드가 너무 짧지 만 논리 자체를 변경해서는 안됩니다. 언뜻보기에 네 번의 호출로 자신을 반복하고있는 것처럼 보이며 checkCondition()코드를주의 깊게 다시 읽은 후에는 각각 다릅니다. 올바른 형식과 기능 이름을 추가해야합니다. 예 :

if (is_an_apple()) {
  addAlert(1);
}
else if (is_a_banana()) {
  addAlert(2);
}
else if (is_a_cat()) {
  addAlert(3);
}
else if (is_a_dog()) {
  addAlert(4);
}

코드는 무엇보다도 읽을 수 있어야합니다. Bob 아저씨의 책 몇 권을 읽은 후에는 그가 계속해서 전달하려는 메시지라고 생각합니다.

모든 함수가 동일한 구성 요소에 구현되어 있다고 가정하면 흐름의 여러 분기를 제거하기 위해 함수가 일부 상태를 유지할 수 있습니다.

EG : checkCondition1()가되어 evaluateCondition1()이전 조건이 충족되었는지 확인합니다. 그렇다면,에 의해 검색 될 값을 캐시합니다 getConditionNumber().

checkCondition2()될 것 evaluateCondition2()이전 조건이 충족 된 경우 확인할 것이다에. 이전 조건이 충족되지 않으면 조건 시나리오 2를 확인하여로 검색 할 값을 캐싱합니다 getConditionNumber(). 등등.

clearConditions();
evaluateCondition1();
evaluateCondition2();
evaluateCondition3();
evaluateCondition4();
if (anyCondition()) { addAlert(getConditionNumber()); }

편집하다:

이 접근 방식이 작동하기 위해 값 비싼 조건에 대한 검사를 구현하는 방법은 다음과 같습니다.

bool evaluateCondition34() {
    if (!anyCondition() && A && B && C) {
        conditionNumber = 5693;
        return true;
    }
    return false;
}

...

bool evaluateCondition76() {
    if (!anyCondition() && !B && C && D) {
        conditionNumber = 7658;
        return true;
    }
    return false;
}

따라서 수행 할 값 비싼 점검이 너무 많고이 코드의 항목이 개인용으로 유지되는 경우,이 접근 방식은이를 유지 보수하는 데 도움이되고 필요한 경우 점검 순서를 변경할 수 있습니다.

clearConditions();
evaluateCondition10();
evaluateCondition9();
evaluateCondition8();
evaluateCondition7();
...
evaluateCondition34();
...
evaluateCondition76();

if (anyCondition()) { addAlert(getConditionNumber()); }

이 답변은 다른 답변의 대안 제안을 제공하며 4 줄의 코드 만 고려하면 원래 코드보다 좋지 않을 것입니다. 비록 내가 언급 한 시나리오를 감안할 때 이것은 끔찍한 접근 방식이 아니며 (다른 사람들이 말한 것처럼 유지 보수를 어렵게하지 않습니다) (너무 많은 검사, 공용으로 노출 된 주요 기능 만 모든 기능이 동일한 클래스의 구현 세부 사항입니다).

둘 이상의 "else"절은 코드를 읽는 사람이 전체 체인을 통해 관심있는 항목을 찾도록합니다. void AlertUponCondition (조건 조건) {스위치 (조건) {case Condition.Con1 : ... break; case Condition.Con2 : ... 단절; etc ...} 여기서 "조건"은 적절한 열거 형입니다. 필요한 경우 부울 또는 값을 반환하십시오. 다음과 같이 호출하십시오. AlertOnCondition (GetCondition ());

실제로 더 간단 해 질 수 없으며 몇 가지 경우를 초과하면 if-else 체인보다 빠릅니다.

코드가 구체적이지 않기 때문에 특정 상황에 대해 말할 수는 없지만 ...

그런 코드는 종종 부족한 OO 모델에 대한 냄새입니다. 실제로는 자체 알림 유형과 관련된 네 가지 유형의 항목이 있지만 이러한 엔티티를 인식하고 각각에 대한 클래스 인스턴스를 작성하는 대신 하나의 항목으로 취급하고 나중에 한 번에 보충하려고 시도합니다. 계속 진행하려면 무엇을 다루어야하는지 알아야합니다.

다형성이 더 적합 할 수 있습니다.

길거나 복잡한 if-then 구문을 포함하는 long 메소드가있는 코드를 의심하십시오. 종종 가상 메소드가있는 클래스 트리가 필요합니다.