폴 스루 스위치 문의 적절한 사용

폴 스루 (클래식) 스위치 문을 사용하는 것이 언제 적절한가요? 그러한 사용을 권장하고 권장합니까 아니면 모든 비용을 피해야합니까?

다음은 유용한 예입니다.

public Collection<LogItems> GetAllLogItems(Level level) {
    Collection<LogItems> result = new Collection<LogItems>();
    switch (level) {
        // Note: fall through here is INTENTIONAL
        case All:
        case Info:
             result.Add(GetItemsForLevel(Info));
        case Warning:
             result.Add(GetItemsForLevel(Warning));
        case Error:
             result.Add(GetItemsForLevel(Error));
        case Critical:
             result.Add(GetItemsForLevel(Critical));
        case None:
    }
    return result;
}

이런 종류의 것 (하나의 경우가 다른 경우를 포함하는 경우)은 드물기 때문에 일부 새로운 언어에서는 대체를 허용하지 않거나 특별한 구문이 필요합니다.

특정 기능을 둘 이상의 값에 적용해야 할 때 사용합니다. 예를 들어 operationCode라는 속성을 가진 개체가 있다고 가정합니다. 코드가 1, 2, 3 또는 4와 같으면 OperationX ()를 시작하려고합니다. 5 또는 6이면 OperationY ()를 시작하고 7을 시작하고 OperationZ ()를 시작하십시오. 폴 스루 (fall-through)를 사용할 수있는 7 가지 기능과 기능을 갖춘 완벽한 사례가있는 이유는 무엇입니까?

특정 상황에서, 특히 100 개의 if-else 문을 피하는 경우 완전히 유효하다고 생각합니다. =)

나는 때때로 그것들을 사용했는데, 나는 항상 적절한 사용법이라고 생각하지만 적절한 의견에 포함되었을 때만.

추락 사례는 완벽하게 좋습니다. 열거 형이 많은 곳에서 사용되는 경우가 종종 있으며, 경우를 구분할 필요가없는 경우 대체 논리를 사용하는 것이 더 쉽다는 것을 알았습니다.

예를 들어 (설명 주석을 참고하십시오) :

public boolean isAvailable(Server server, HealthStatus health) {
  switch(health) {
    // Equivalent positive cases
    case HEALTHY:
    case UNDER_LOAD:
      return true;

    // Equivalent negative cases
    case FAULT_REPORTED:
    case UNKNOWN:
    case CANNOT_COMMUNICATE:
      return false;

    // Unknown enumeration!
    default:
      LOG.warn("Unknown enumeration " + health);
      return false;
  }
}

나는 이런 종류의 사용이 완벽하게 수용 가능하다는 것을 알았습니다.

그것은에 달려 있습니다 :

• 당신의 개인적인 취향
• 고용주의 코딩 표준
• 관련된 위험 량

한 사례가 다음 사례로 넘어가는 것과 관련된 두 가지 주요 문제는 다음과 같습니다.

1. 코드가 case 문의 순서에 따라 달라집니다. 당신이 결코 빠져들지 않는다면 그것은 사실이 아니며, 종종 환영받지 못하는 복잡성을 추가합니다.

2. 하나의 사례에 대한 코드에 하나 이상의 후속 사례에 대한 코드가 포함되어 있는지 확실하지 않습니다.

어떤 곳은 넘어지는 것을 명시 적으로 금지합니다. 그런 곳에서 일하지 않고 연습에 익숙하고 문제의 코드를 깨뜨려도 큰 고통을 겪지 않는다면 세계에서 최악의 일은 아닐 수도 있습니다. 하지만 그렇게한다면, 나중에 오는 사람들 (미래를 포함하여)에게 경고하기 위해주의를 끄는 논평을 가까운 곳에 두십시오.

다음은 내 인생을 더 단순하게 만드는 추락의 빠른 (완전히 불완전한 (윤년의 특별한 처리 없음)) 예입니다.

function get_julian_day (date) {
    int utc_date = date.getUTCDate();
    int utc_month = date.getUTCMonth();

    int julian_day = 0;

    switch (utc_month) {
        case 11: julian_day += 30;
        case 10: julian_day += 31;
        case 9:  julian_day += 30;
        case 8:  julian_day += 31;
        case 7:  julian_day += 31;
        case 6:  julian_day += 30;
        case 5:  julian_day += 31;
        case 4:  julian_day += 30;
        case 3:  julian_day += 31;
        case 2:  julian_day += 28;
        case 1:  julian_day += 31;
        default: break;
    }

    return julian_day + utc_date;
}

한 사례에서 다른 사례로 갈 필요가 있다고 느낀다면 (드물게, 물론), 나는 goto case당신의 언어가 그것을 지원한다고 가정합니다.

쓰루를 통해 떨어지는 것은 매우 드문 일이며 코드를 읽는 동안 간과하기가 매우 쉽기 때문에 명시 적 인 것이 적절하다고 생각합니다.

또한 case 문을 다시 정렬 할 때 발생할 수있는 버그를 피하는 데 도움이됩니다.