모든 조건을 충족해야하는 경우에 사다리-중복 최종 조항을 추가해야합니까?

이것은 내가 최근에 많이하고있는 일이다.

예:

setCircle(circle, i, { current }) {
    if (i == current) {
        circle.src = 'images/25CE.svg'
        circle.alt = 'Now picking'
    } else if (i < current) {
        circle.src = 'images/25C9.svg'
        circle.alt = 'Pick failed'
    } else if (i > current) {
        circle.src = 'images/25CB.svg'
        circle.alt = 'Pick chance'
    }
}

종종 if / else 사다리는 이것보다 훨씬 더 복잡합니다 ...

마지막 조항을 참조하십시오? 중복입니다. 사다리는 궁극적으로 가능한 모든 조건을 잡아야합니다. 따라서 다음과 같이 다시 작성할 수 있습니다.

setCircle(circle, i, { current }) {
    if (i == current) {
        circle.src = 'images/25CE.svg'
        circle.alt = 'Now picking'
    } else if (i < current) {
        circle.src = 'images/25C9.svg'
        circle.alt = 'Pick failed'
    } else {
        circle.src = 'images/25CB.svg'
        circle.alt = 'Pick chance'
    }
}

이것이 내가 코드를 작성하는 데 사용한 방법이지만이 스타일을 싫어합니다. 내 불만은 코드의 마지막 부분이 실행될 조건이 코드에서 명확하지 않다는 것입니다. 따라서이 조건을보다 분명하게 작성하기 위해 명시 적으로 작성하기 시작했습니다.

하나:

• 명백하게 최종 소진 상태를 작성하는 것은 내 자신의 아이디어이며, 나는 내 자신의 아이디어에 대한 나쁜 경험을 가지고 있습니다. 일반적으로 사람들은 내가하고있는 일이 얼마나 끔찍한 지에 대해 비명을 지 릅니다. 차선책;
• 이것이 나쁜 생각 일 수있는 한 가지 힌트 : Javascript에는 적용되지 않지만 다른 언어에서는 컴파일러가 함수의 끝에 도달하는 제어에 대한 경고 또는 오류를 발생시키는 경향이 있습니다. 그런 일을하는 것은 너무 인기가 없거나 잘못하고 있습니다.
  • 컴파일러 불만으로 인해 때로는 의견에 최종 조건을 쓰게되었지만 코드와 달리 의견이 실제 프로그램 의미에 영향을 미치지 않기 때문에 그렇게하는 것이 끔찍한 것 같습니다.

    } else { // i > current
        circle.src = 'images/25CB.svg'
        circle.alt = 'Pick chance'
    }

뭔가 빠졌습니까? 아니면 내가 묘사 한 것을하는 것이 좋습니까, 아니면 나쁜 생각입니까?

두 가지 방법 모두 유효합니다. 그러나 장단점을 자세히 살펴 보겠습니다.

를 들어 if사소한 조건 쇄, 정말 중요하지 않습니다 여기에 같은 :

• final로 else독자가 어떤 조건에서 다른 조건이 트리거되는지 알아내는 것이 분명합니다.
• 마지막으로 else if, 독자가 else모두 다루었 으므로 추가 사항 이 필요 하지 않다는 것이 분명 합니다.

그러나 if여러 변수의 상태를 복잡한 논리식과 결합하여 더 복잡한 조건에 의존하는 많은 체인이 있습니다. 이 경우 덜 분명합니다. 그리고 각 스타일의 결과는 다음과 같습니다.

• final else: 브랜치 중 하나가 선택되었음을 확신합니다. 하나의 사례를 잊어 버린 경우 마지막 분기를 거치므로 디버깅 중에 마지막 분기를 선택하고 다른 것을 예상 한 경우 신속하게 알아낼 수 있습니다.
• final else if: 코드에 대한 중복 조건을 도출해야하며, 이로 인해 모든 경우를 다루지 않는 잠재적 인 오류 소스가 생성됩니다. 또한 사례를 놓친 경우 아무 것도 수행되지 않으며 무언가 누락 된 것을 찾는 것이 더 어려울 수 있습니다 (예 : 설정해야하는 일부 변수가 이전 반복에서 값을 유지하는 경우).

따라서 최종 중복 조건은 위험의 원천입니다. 이것이 내가 파이널에 가기를 제안하는 이유 else입니다.

편집 : 고 신뢰성 코딩

높은 신뢰성을 염두에두고 개발하는 경우 예기치 않은 상황을 포착하기 위해 중복 명시 적 결승 else if을 결승 으로 완료하는 다른 변형이 필요할 수 있습니다 else.

이것은 방어적인 코딩입니다. SEI CERT 또는 MISRA 와 같은 일부 보안 사양에서 권장됩니다 . 일부 정적 분석 도구 는이를 체계적으로 검사 하는 규칙 으로 구현하기도 합니다 (컴파일러 경고를 설명 할 수 있음).

지금까지 답변에서 누락 된 것은 어떤 종류의 실패가 덜 해로운 지의 문제입니다.

당신의 논리가 좋으면 실제로 당신이하는 일이 중요하지 않으며, 중요한 경우는 버그가있는 경우에 발생합니다.

최종 조건을 생략합니다. 최종 옵션이 옳지 않은 경우에도 실행됩니다.

최종 조건을 추가하기 만하면됩니다. 상황에 따라 옵션이 실행되지 않습니다. 상황에 따라 단순히 표시에 실패하거나 (해가 적음) 나중에 나중에 null 참조 예외가 발생할 수 있습니다 (디버깅 일 수 있음) 고통.)

최종 조건부와 예외를 추가합니다.

이러한 옵션 중 가장 적합한 옵션을 결정해야합니다. 개발 코드에서 나는 이것을 생각할 필요가 없다고 생각한다. 세 번째 경우를 보라. 그러나, 아마도 circle.src를 오류 이미지로 설정하고 circle.alt를 던지기 전에 오류 메시지로 설정했을 것입니다. 누군가 나중에 어설 션을 해제하기로 결정하면이로 인해 오류가 발생하지 않습니다.

고려해야 할 또 다른 사항-복구 옵션은 무엇입니까? 때로는 복구 경로가 없습니다. 내가 생각하는 것은 이것이 Ariane V 로켓의 첫 발사입니다. 부스터가 파괴되는 잡히지 않은 / 0 (실제로 나누기 오버플로) 오류가 발생했습니다. 실제로 충돌 한 코드는 그 시점에서 어떤 목적도 달성하지 못했으며, 스트랩 온 부스터가 점등되는 순간에 무력화되었습니다. 그들이 궤도 또는 붐에 불이 들어 오면 최선을 다하고 오류를 허용 할 수 없습니다. (이로 인해 로켓이 길을 잃으면 범위 안전 요원이 열쇠를 돌립니다.)

내가 추천하는 것은 assert마지막 두 가지 스타일 중 하나를 사용하는 것입니다.

setCircle(circle, i, { current }) {
    if (i == current) {
        circle.src = 'images/25CE.svg'
        circle.alt = 'Now picking'
    } else if (i < current) {
        circle.src = 'images/25C9.svg'
        circle.alt = 'Pick failed'
    } else {
        assert i > current
        circle.src = 'images/25CB.svg'
        circle.alt = 'Pick chance'
    }
}

또는 데드 코드 어설 션 :

setCircle(circle, i, { current }) {
    if (i == current) {
        circle.src = 'images/25CE.svg'
        circle.alt = 'Now picking'
    } else if (i < current) {
        circle.src = 'images/25C9.svg'
        circle.alt = 'Pick failed'
    } else if (i > current) {
        circle.src = 'images/25CB.svg'
        circle.alt = 'Pick chance'
    } else {
        assert False, "Unreachable code"
    }
}

코드 범위 도구는 종종 범위 보고서에서 "assert False"와 같은 코드를 무시하도록 구성 될 수 있습니다.

조건을 어설 션에 넣으면 분기의 조건을 명시 적으로 문서화 할 수 있지만 주석과 달리 어설 션 조건을 실제로 확인할 수 있으며 개발 중이나 프로덕션 환경에서 어설 션을 사용하도록 설정하면 실패합니다 (일반적으로 어설 션을 사용하도록 설정하는 것이 좋습니다) 성능에 너무 영향을 미치지 않으면 프로덕션에서).

조건을 평가하는 "어설 션 된"매크로를 정의했으며 디버그 빌드에서는 디버거에 속합니다.

따라서 세 가지 조건 중 하나에 해당되는지 100 % 확신한다면 다음과 같이 씁니다.

If condition 1 ...
Else if condition 2 .,,
Else if asserted (condition3) ...

따라서 하나의 조건이 충족되고 어설 션에 대한 추가 분기가 필요하지 않다는 것이 명확 해집니다.

나는 완전히 다른 것을 피하는 것이 좋습니다 . 사용하여 if코드 블록이 손잡이로되어 있는지를 선언하고, 기능을 종료하여 블록을 종료합니다.

결과적으로 매우 명확한 코드가 생성됩니다.

setCircle(circle, i, { current })
{
    if (i == current)
    {
        circle.src = 'images/25CE.svg'
        circle.alt = 'Now picking'
        return
    }
    if (i < current)
    {
        circle.src = 'images/25C9.svg'
        circle.alt = 'Pick failed'
        return
    }
    if (i > current)
    {
        circle.src = 'images/25CB.svg'
        circle.alt = 'Pick chance'
        return
    }
    throw new Exception("Condition not handled.");
}

마지막 if은 물론 중복입니다 ... 오늘. 미래의 일부 개발자가 블록을 다시 정렬하면 매우 중요한 생각이 될 수 있습니다. 거기에두면 도움이됩니다.