If/Else If가 아닌 전환/대소문자를 바꾸는 이유

If/Else If가 아닌 전환/대소문자를 바꾸는 이유

이 문제는 주로 C/C++를 지적했지만 다른 언어들도 관련이 있을 것 같다.

나는 왜 if/else가 아닌 switch/case가 여전히 사용되는지 이해할 수 없다.내가 보기엔 Goto's를 사용하는 것과 많이 닮았고, 같은 종류의 지저분한 코드가 만들어지는 반면, 같은 결과가 훨씬 더 조직적인 방법으로 만들어질 수 있다.

그래도 나는 이 블록들을 꽤 자주 본다.이들을 찾는 흔한 장소는 메시지 루프(WndProc...) 근처인 반면, 이들이 가장 큰 혼란을 일으키는 장소들 중 하나이다. 변수는 소유권이 없는 경우에도 전체 블록을 따라 공유된다(그리고 그 안에서 초기화할 수 없다).휴식시간을 주지 않도록 각별히 신경써야 한다. 그래서...

개인적으로, 나는 그것들을 사용하는 것을 피하는데, 내가 무언가를 놓치고 있는 것이 더 궁금하다.

if/else보다 더 효율적인가?그것들은 전통에 의해 계승되는가?

내 초기 게시물과 의견을 요약하는 것 - 몇 가지 장점이 있다.switch에 대한 진술.if/else문:

1. 청정 코드.여러 체인이 연결된 코드if/else if ...지저분해 보이고 유지하기도 어렵다.switch보다 깨끗한 구조를 제공한다.

2. 퍼포먼스밀도를 위해case값 컴파일러는 스파스 - 이진 검색 또는 일련의 작업에 대해 점프 테이블을 생성함if/else그래서 최악의 경우에는.switch만큼 빠르다if/else, 그러나 전형적으로 더 빠르다.비록 일부 컴파일러가 비슷하게 최적화할 수 있지만if/else.

3. 시험 순서는 중요하지 않다.다음 시리즈의 속도를 높이려면if/else테스트는 더 가능성이 있는 경우를 우선시할 필요가 있다.같이.switch/case프로그래머는 이것에 대해 생각할 필요가 없다.

4. 기본값은 어디에나 있을 수 있다.같이.if/else디폴트 케이스는 맨 끝에 있어야 함 - 마지막으로else . in.switch-default프로그래머가 더 적합하다고 생각하는 곳이라면 어디든 있을 수 있다.

5. 공통 코드.몇 가지 경우에 대해 공통 코드를 실행해야 할 경우, 생략할 수 있다.break그리고 사형 집행은 "실패"할 것이다 - 당신이 성취할 수 없는 것.if/else. (특별한 코멘트를 붙이는 좋은 관행이 있다./* FALLTHROUGH */이러한 경우 - 보풀은 그것을 인식하고 불평하지 않으며, 이 코멘트가 없으면 잊어버리는 것이 일반적인 오류이기 때문에 불평을 한다.break).

코멘트해줘서 고마워.

또한 스위치 문을 사용하면 제어 흐름이 지속되므로 조건이 잘 결합되는 동시에 다음 코드 조각과 같은 특정 조건에 대해 코드를 추가할 수 있다는 점을 기억하십시오.

switch (dayOfWeek)
{
    case MONDAY:
        garfieldUnhappy = true;
    case TUESDAY:
    case WEDNESDAY:
    case THURSDAY:
    case FRIDAY:
       weekDay = true;
       break;
    case SATURDAY:
       weekendJustStarted = true;
    case SUNDAY:
       weekendDay = true;
       break;
}

사용.if/else대신 여기에서의 진술은 좋은 곳이 아닐 것이다.

if (dayOfWeek == MONDAY)
{
    garfieldUnhappy = true;
}
if (dayOfWeek == SATURDAY)
{
    weekendJustStarted = true;
}
if (dayOfWeek == MONDAY || dayOfWeek == TUESDAY || dayOfWeek == WEDNESDAY
    || dayOfWeek == THURSDAY || dayOfWeek == FRIDAY)
{
    weekDay = true;
}
else if (dayOfWeek == SATURDAY || dayOfWeek == SUNDAY)
{
    weekendDay = true;
}

케이스가 많으면 스위치 문장이 더 깨끗해 보인다.

또한 동일한 행동을 원하는 여러 값을 가질 때도 좋다 - 하나의 구현으로 이어지는 여러 "사례" 문구를 사용하는 것이 if(이 || 저 || 다른 것 || )보다 훨씬 읽기 쉽다.

또한 언어에 따라 다를 수 있음 - 예를 들어, 일부 언어 스위치는 숫자 유형에서만 작동하므로 열거된 값, 숫자 상수로 작업할 때 일부 타이핑을 저장할 수 있음...기타...

If (day == DAYOFWEEK_MONDAY) {
    //...
}
else if (day == DAYOFWEEK_TUESDAY) {
    //...
}
//etc...

아니면 읽기가 조금 더 쉽거나...

switch (day) {
    case DAYOFWEEK_MONDAY :
        //...
    case DAYOFWEEK_TUESDAY :
        //...
    //etc...
}

사례/선택이 추가적인 유연성을 제공한다는 점을 기억하십시오.

• 상태를 한 번 평가한다.
• 더프의 장치 같은 것을 만들 수 있을 만큼 충분히 유연하다.
• fall through(단순히 중단되지 않은 경우

훨씬 더 빠른 실행 속도(점프/스케줄 테이블을 통해 * 역사적으로

글쎄, 한 가지 이유는 명확성...

만약 스위치/케이스가 있다면, 그 표현은 바뀔 수 없다....즉.

switch (foo[bar][baz]) {
case 'a':
    ...
    break;
case 'b': 
    ...
    break;
}

반면 if/properties를 사용하여 잘못(또는 의도)하여 쓰는 경우:

if (foo[bar][baz] == 'a') {
    ....
}
else if (foo[bar][baz+1] == 'b') {
    ....
}

당신의 코드를 읽는 사람들은 "동일해야 하는 foo표현" 혹은 "왜 다른가"를 궁금해 할 것이다.

명료함여기서 말했듯이, 그 단서는else if문제가 있는 것은

구문에 의해 허용된 것보다 훨씬 더 제한적인 방법으로 EASTER IF가 사용되는 빈도그것은 유연성의 해머로, 전혀 관련이 없는 조건들을 시험할 수 있게 한다.그러나 그것은 CASE의 파리를 다른 값과 비교하면서 일상적으로 사용된다...

이것은 코드의 가독성을 감소시킨다.구조는 조건부 복잡성의 우주를 허용하므로, 독자는 CASE를 구문 분석할 때보다 ERSE IF를 구문 분석할 때 더 많은 가능성을 염두에 둘 필요가 있다.

사실 스위치 문장은 당신이 무슨 일이 일어나고 있는지 즉각적으로 단서를 주는 다소 열거적인 것으로 일하고 있다는 것을 암시한다.

즉, 어떤 OO 언어의 열거형 스위치는 아마도 더 잘 코딩될 수 있으며, 동일한 "에넘어" 스타일 값에 대한 일련의 if/else는 적어도 의미를 전달하는 데 있어서 그만큼 나쁘고 더 나쁠 것이다.

같은 방법으로 컴파일할 수 있을 겁니다if/else if그러나 나는 그 것을 찾았다.switch/case2개 또는 3개 이상일 때 읽기 쉽다.elses

일반적으로 스위치/케이스는 if/else if/else보다 더 효율적으로 최적화되지만 if/else 문장으로 변환되는 경우가 있다(언어 및 컴파일러에 따라 다름).

나는 개인적으로 스위치 문장이 많은 if 문보다 코드를 더 읽기 쉽게 만든다고 생각한다. 단 몇 가지 간단한 규칙을 따른다면 말이다.만약/만일/만일 상황이라도 당신이 따라야 할 규칙들, 그러나 그것은 다시 나의 의견이다.

다음 규칙:

• 절대로 스위치 블록에 줄이 두 개 이상 있으면 안 된다.메소드나 함수를 불러 그곳에서 일을 해라.
• 항상 파손/대상이 제대로 전달되지 않았는지 확인하십시오.
• 예외를 버블업하다.

스위치 내부의 모든 것이 동등한 범위를 가지고 있다는 우려를 해소하면서, 항상 케이스 논리를 다른 {} 블록에 던질 수 있다.

switch( thing ) {
    case ONETHING: {
        int x; // local to the case!
        ...
        }
        break;
    case ANOTHERTHING: {
        int x; // a different x than the other one
        }
        break;
}

..이젠 그게 예쁘다고 말하는게 아니야.한 케이스에서 다른 케이스와 분리해야 한다면 가능한 것으로 밖에 내놓는 겁니다.

스코프 문제에 대한 다른 한 가지 생각 - 한 기능 안에 스위치를 하나만 넣고 다른 기능은 많이 넣지 않는 것이 좋은 관행처럼 보인다.이러한 상황에서, 가변 범위는 그다지 큰 문제가 되지 않는다. 왜냐하면 그렇게 함으로써 당신은 일반적으로 주어진 함수의 호출에 대해 하나의 실행 사례만을 다루게 되기 때문이다.

좋아, 스위치에 대한 마지막 생각: 만약 어떤 기능에 스위치가 두어 개 이상 포함되어 있다면, 이제 코드를 리팩터링할 때가 된 것 같다.함수에 내포된 스위치가 포함되어 있는 경우 설계를 약간 다시 생각해 볼 수 있는 단서가 될 수 있음 =)

스위치 케이스는 주로 프로그래밍에서 선택하기 위해 사용된다.이것은 다음과 같은 조건문과는 관련이 없다.

만약 당신의 프로그램이 당신이 if/program block을 사용하는 이유와 그것이 프로그램의 실행 속도를 감소시키는 이유를 선택하도록 요구한다면.

스위치 문장은 속도에 최적화될 수 있지만, 케이스 값이 많은 수의 값에 걸쳐 분산될 경우 더 많은 메모리를 차지할 수 있다.

각 값을 확인해야 하므로 일반적으로 속도가 느릴 경우.

스몰토커는 스위치와 if-else를 모두 거부하고 다음과 같은 글을 쓸 수 있다.

shortToLongDaysMap := Dictionary new.

shortToLongDaysMap
at: 'Mon'     put:  'Monday';
at: 'Tue'     put:  'Tuesday';
at: 'Wed'     put:  'Wednesday'
etc etc.

longForm := shortToLongDaysMap at: shortForm ifAbsent: [shortForm]

이것은 사소한 예지만 이 기법이 많은 경우에 어떻게 확장되는지 볼 수 있기를 바란다.

두 번째 인수를 참고하십시오.at:IfAbsent:사례 진술의 기본 조항과 유사하다.

이것의 주된 이유는 유지 보수성과 가독성이다.스위치/케이스 문으로 코드를 더 읽기 쉽고 유지 관리할 수 있도록 하는 것이 가능하다.왜냐하면 당신은 많은 if/else를 가지고 있기 때문에 코드가 둥지처럼 지저분해지고 그것을 유지하는 것은 매우 어렵다.

그리고 사형 집행 시간이 또 다른 이유야

참조URL: https://stackoverflow.com/questions/1028437/why-switch-case-and-not-if-else-if