Switch 문 폴 스루… 허용되어야합니까? [닫은]

내가 기억할 수있는 한 나는 switch 문 폴 스루 사용을 피했다. 사실, 나는 그것이 스위치 문장의 버그에 지나지 않는다는 것을 일찍 내 머리에 뚫었 기 때문에 가능한 일을 할 수있는 방법으로 내 의식에 들어가는 것을 기억할 수 없습니다. 그러나 오늘 나는 그것을 디자인에 의해 사용하는 일부 코드를 만났고, 이것은 커뮤니티의 모든 사람들이 switch 문 폴 스루에 대해 어떻게 생각하는지 즉시 궁금해했습니다.

프로그래밍 언어가 명시 적으로 허용해서는 안되는 것입니까 (해결책을 제공하지만 C #처럼) 아니면 프로그래머의 손에 맡길 수있을만큼 강력한 언어의 기능입니까?

편집 : 나는 폴스 루가 의미하는 바에 대해 충분히 구체적이지 않았습니다. 이 유형을 많이 사용합니다.

    switch(m_loadAnimSubCt){
        case 0:
        case 1:
            // Do something
            break;
        case 2:
        case 3:
        case 4:
            // Do something
            break;
   }

그러나 나는 이와 같은 것에 대해 걱정합니다.

   switch(m_loadAnimSubCt){
        case 0:
        case 1:
            // Do something, but fall through to the other cases
            // after doing it.

        case 2:
        case 3:
        case 4:
            // Do something else.
            break;
   }

이렇게하면 case가 0, 1 일 때마다 switch 문에서 모든 작업을 수행합니다. 나는 이것을 의도적으로 보았고 switch 문을 이런 방식으로 사용해야한다는 데 동의하는지 모르겠습니다. 첫 번째 코드 예제는 매우 유용하고 안전하다고 생각합니다. 두 번째는 위험 해 보입니다.

그것은 당신이 폴 스루라고 생각하는 것에 달려 있습니다. 나는 이런 종류의 일로 괜찮습니다.

switch (value)
{
  case 0:
    result = ZERO_DIGIT;
    break;

  case 1:
  case 3:
  case 5:
  case 7:
  case 9:
     result = ODD_DIGIT;
     break;

  case 2:
  case 4:
  case 6:
  case 8:
     result = EVEN_DIGIT;
     break;
}

그러나 케이스 라벨 뒤에 다른 케이스 라벨로 넘어가는 코드가 있다면, 저는 거의 항상 그 악한 것으로 간주합니다. 아마도 공통 코드를 함수로 옮기고 두 곳에서 호출하는 것이 더 좋은 생각 일 것입니다.

그리고 "악" 의 C ++ FAQ 정의를 사용합니다.

양날의 검입니다. 때로는 매우 유용하지만 종종 위험합니다.

언제 좋은가요? 10 개의 케이스를 모두 동일한 방식으로 처리하려면 ...

switch (c) {
  case 1:
  case 2:
            ... Do some of the work ...
            /* FALLTHROUGH */
  case 17:
            ... Do something ...
            break;
  case 5:
  case 43:
            ... Do something else ...
            break;
}

내가 좋아하는 한 가지 규칙은 휴식을 제외하고 멋진 일을 한 적이 있다면 / * FALLTHROUGH * /라는 명확한 주석이 필요하다는 것입니다.

Duff의 장치에 대해 들어 보셨습니까 ? 이것은 스위치 폴 스루를 사용하는 좋은 예입니다.

거의 모든 언어 기능처럼 사용할 수 있고 남용 될 수있는 기능입니다.

폴 스루는 당신이하는 일에 따라 정말 편리한 일입니다. 옵션을 정렬하는 깔끔하고 이해하기 쉬운 방법을 고려하십시오.

switch ($someoption) {
  case 'a':
  case 'b':
  case 'c':
    // Do something
    break;

  case 'd':
  case 'e':
    // Do something else
    break;
}

if / else로 이것을한다고 상상해보십시오. 엉망이 될 것입니다.

몇 번은 매우 유용 할 수 있지만 일반적으로 폴 스루는 원하는 동작이 아닙니다. 폴 스루는 허용되어야하지만 암시 적이 어서는 안됩니다.

예를 들어 일부 데이터의 이전 버전을 업데이트하려면 다음을 수행하십시오.

switch (version) {
    case 1:
        // Update some stuff
    case 2:
        // Update more stuff
    case 3:
        // Update even more stuff
    case 4:
        // And so on
}

스위치의 폴백에 대해 다른 구문을 원합니다.

switch(myParam)
{
  case 0 or 1 or 2:
    // Do something;
    break;
  case 3 or 4:
    // Do something else;
    break;
}

참고 : 플래그를 사용하여 열거 형의 모든 케이스를 선언하면 열거 형으로 이미 가능할 것입니다. 그렇게 나쁘게 들리지는 않습니다. 케이스는 이미 열거 형의 일부가 될 수 있습니다.

아마도 이것은 확장 메서드를 사용하는 유창한 인터페이스에 대한 좋은 사례 (말장난이 아님)일까요? 뭐, 음 ...

int value = 10;
value.Switch()
  .Case(() => { /* Do something; */ }, new {0, 1, 2})
  .Case(() => { /* Do something else */ } new {3, 4})
  .Default(() => { /* Do the default case; */ });

가독성이 떨어질 수 있지만 : P

다른 것과 마찬가지로 조심스럽게 사용하면 우아한 도구가 될 수 있습니다.

그러나 단점 은 사용 하지 않는 것을 정당화 하고 마침내 더 이상 허용하지 않는 것 이상이라고 생각합니다 (C #). 문제는 다음과 같습니다.

• 휴식을 "잊기"쉽습니다.
• 생략 된 중단이 의도적 이라는 것이 코드 관리자 에게 항상 분명한 것은 아닙니다.

스위치 / 케이스 폴 스루 사용 :

switch (x)
{
case 1:
case 2:
case 3:
 Do something
 break;
}

스위치 / 케이스 폴 스루 사용 :

switch (x)
{
case 1:
    Some code
case 2:
    Some more code
case 3:
    Even more code
    break;
}

이것은 내 의견으로는 전혀 손실없이 if / else 구문을 사용하여 다시 작성할 수 있습니다.

내 마지막 단어 : 이 스타일이 사용되고 잘 이해되는 레거시 코드를 유지하지 않는 한 , 나쁜 예 에서와 같이 폴 스루 케이스 레이블을 멀리하십시오 .

강력하고 위험합니다. 폴 스루의 가장 큰 문제는 그것이 명시 적이 지 않다는 것입니다. 예를 들어, 폴스 루가있는 스위치가있는 자주 편집되는 코드를 발견하면 이것이 의도적 인 것이며 버그가 아니라는 것을 어떻게 알 수 있습니까?

내가 사용하는 곳 어디에서나 적절하게 주석을 달았는지 확인합니다.

switch($var) {
    case 'first':
        // Fall-through
    case 'second':
        i++;
        break;
 }

첫 번째 예제에서와 같이 폴 스루를 사용하는 것은 분명히 괜찮으며 실제 폴 스루라고 생각하지 않습니다.

두 번째 예는 위험하며 (광범위하게 설명하지 않으면) 명확하지 않습니다. 저는 학생들에게 주석 블록을 할당하는 노력의 가치가 있다고 생각 하지 않는 한 이러한 구성을 사용하지 않도록 가르칩니다 . 이는 이것이 의도적 인 실패이며이 솔루션이 대안보다 나은 이유를 설명합니다. 이것은 엉성한 사용을 막지 만 이점으로 사용되는 경우에는 여전히 허용됩니다.

이것은 누군가가 코딩 표준을 위반하기를 원했을 때 우주 프로젝트에서했던 것과 거의 동일합니다. 그들은 섭리를 신청해야했습니다 (그리고 판결에 대한 조언을 요청 받았습니다).

나는 내 switch진술이 실패하는 것을 좋아하지 않습니다. 너무 오류가 많고 읽기가 어렵습니다. 유일한 예외는 여러 case명령문이 모두 정확히 동일한 작업을 수행 하는 경우입니다.

switch 문의 여러 분기에서 사용하려는 공통 코드가있는 경우 모든 분기에서 호출 할 수있는 별도의 공통 함수로 추출합니다.

어떤 경우에는 폴 스루를 사용하는 것이 프로그래머의 게으름 행위입니다. 일련의 || 예를 들어, 대신 일련의 '범용'스위치 케이스를 사용합니다.

즉, 결국에는 특히 도움이된다는 것을 알게 되었습니다. 어쨌든 옵션이 필요하다는 것을 알지만 (예를 들어 메뉴 응답에서) 아직 모든 선택을 구현하지 않았을 습니다. 마찬가지로 'a'와 'A'모두에 대해 폴 스루를 수행하는 경우 복합 if 문보다 스위치 폴 스루를 사용하는 것이 훨씬 더 깨끗합니다.

아마도 스타일과 프로그래머가 생각하는 방식의 문제 일 수 있지만 일반적으로 '안전'이라는 이름으로 언어의 구성 요소를 제거하는 것을 좋아하지 않습니다. 이것이 제가 C와 그 변형 / 후손을 선호하는 이유입니다. 자바. 나는 "이유"가 없을 때에도 포인터 등으로 주위를 돌아 다니는 것을 좋아한다.

폴 스루는 코드 블록에 대한 점프 테이블로 사용되는 경우에만 사용해야합니다. 더 많은 케이스 이전에 무조건적인 중단이있는 코드 부분이 있으면 모든 케이스 그룹이 그런 방식으로 종료되어야합니다.

다른 것은 "악"입니다.