programing

다른 경우가 아니라 반품/계속 문을 사용해야 합니까?

css3 2023. 10. 7. 12:07

다른 경우가 아니라 반품/계속 문을 사용해야 합니까?

C, C++, C#에서 함수나 루프 문 내부의 조건을 사용할 때는 가능한 한 빨리 continuereturn 문을 사용하고 if-else 문의 다른 가지를 없애는 것이 가능합니다.예를 들어,

while( loopCondition ) {
    if( innerCondition ) {
        //do some stuff
    } else {
        //do other stuff
    }
}

된다

 while( loopCondition ) {
    if( innerCondition ) {
        //do some stuff
        continue;
    }
    //do other stuff
}

그리고.

void function() {
    if( condition ) {
        //do some stuff
    } else {
        //do other stuff
    }
}

된다

void function() {
    if( condition ) {
        //do some stuff
        return;
    }
    //do other stuff
}

if-else 분기가 길면 다른 분기에 대한 들여쓰기가 없어지기 때문에 "After" 변형이 더 잘 읽힐 수 있습니다.

반품/계속 사용하는 것이 좋은 생각입니까?유지보수나 가독성에 문제가 있습니까?

인 접근방법은 if).다대 3는 줄),합니다.return/continue변주 차체가 길면 제어 흐름을 파악하기 어려워 선택합니다를 선택합니다.else

으로 이 으로, 으로, 합니다의 합니다.return/continue다음 방법하나를 사용하여 데이터를 처리하는 보다 일부 데이터를 건너뛰고 이상의 처리를 피하는 스타일(다음 방법이 더 적합함)if/else).

종료 기준을 먼저 처리하면 코드가 더 잘 읽힐 것입니다.저는 긴 코드 실행이 필요한 조건보다는 휴식이나 복귀가 필요한 조건을 확인하는 것을 항상 선호합니다.나는 다음을 선호합니다.

 if (termination condn) 
      return;
 // code 
 // code

로.

if (success condn)
{
  // code
  // code
}
else
 return;

이것은 코드를 읽고 이해하는 것을 더 쉽게 해줍니다.

컴파일러는 거의 틀림없이 같은 코드를 생성할 것입니다.그렇지 않았더라도 그 차이는 아마도 무관할 것입니다.따라서 관련된 논쟁은 확실히 사람들이 그것을 어떻게 읽을 것인가 하는 것입니다.

따라서 문제는 "//do something"과 "do something"이 얼마나 비슷한지 입니다.개념적으로 유사한 경우 if/else를 사용합니다.개념적으로 다를 경우 계속/반환을 사용합니다.

나뭇가지의 길이에 따라 조금씩 다릅니다.환다인 하는 것이 .if체크는 짧고 몸은 깁니다.if그리고.else부품이 길기 때문에 별도의 기능으로 추출할 수 있습니다.

저는 코드 컴플리트를 읽는 것을 추천합니다, 이런 것들에 대해 많이 이야기합니다.

모든 것이 달렸다는 것이 입에 맞는 대답입니다.

condition 또는 드예: null인)다를 이 있습니다.return아니면continue

예상되는 경우라면 당신의 첫 번째 접근법을 이용하는 편입니다.

하지만 제가 "부드럽다"고 말한 것을 주목하세요.이들과 조건의 경계는 모호하며 프로젝트와 제가 누구와 함께 일하는지에 따라 변경될 수 있습니다.

저는 평소에 더 좋습니다.

while( loopCondition ) {
    if( innerCondition ) {
        DoStuff();
    } else {
        DoOtherStuff(); 
    }
}

계속은 DoStuff의 길이가 1-2행 임계값을 통과한 경우(의도를 놓치기 꽤 쉬운 경우) 따라가기 어려울 수 있습니다.이것은 논리를 몇 가지 더 작은 방법으로 재분류할 수 있는 좋은 기회인 것 같습니다.

조기 최적화를 위해 가독성을 희생하지 마십시오.

예를 들어,

void function() {
    if( condition ) {
        //do some stuff
    } else {
        //do other stuff
    }
}

는 대부분의 경우 다음과 같은 이진수입니다.

void function() {
    if( condition ) {
        //do some stuff
        return;
    }
    //do other stuff
}

(즉, 결과 코드는 아마도 동일할 것입니다.)그러나 코드가 X 또는 Y 중 하나에 적용되는 것을 명확하게 알 수 있기 때문에 전자의 가독성이 훨씬 더 좋습니다.

1) 입력 또는 개체 상태 유효성 검사.다음 코드:

void function() {
    if( condition ) {
        //do some stuff
        return;
    }
    //do other stuff
}

기능이 작동하기 위한 조건일 때 좋습니다.입력 검증 또는 개체 상태 검증 단계입니다.그런 다음 기능이 전혀 실행되지 않았다는 점을 강조하기 위해 즉시 리턴을 사용하는 것이 옳다고 생각합니다.

2) 다단계 처리.루프가 일부 컬렉션에서 요소를 팝하고 다단계 방식으로 처리할 때/계속하는 것이 좋습니다.

while(foo = bar.getNext()) {
   if(foo.empty())
       continue;
   if(foo.alreadyProcessed())
       continue;
   // Can we take a shortcut?
   if(foo.tryProcessThingsYourself())
       continue;
   int baz = foo.getBaz();
   if(baz < 0) {
       int qux = foo.getQux();
       if(qux < 0) {
         // Error - go to next element
         continue;
       }
   }
   // Finally -- do the actual processing
   baz = baz * 2;
   foo.setBaz(baz);
}

이 예는 여러 곳에서 다양한 조건으로 인해 각 처리가 중단될 수 있는 경우, 일련의 다단계 처리가 이루어질 때 시나리오에서 계속 사용하는 것이 얼마나 자연스러운지 보여줍니다.

참고: 플린스는 2)가 말하는 실제 예시를 게시했습니다.

3) 일반적인 규칙.나는 계속을 사용하고 무언가가 중단되었다는 사실과 일치할 때 반환합니다.는 다른 것이 실제 처리의 일부일 때 사용합니다.

한 가지 가능한 유지보수 문제는 함수에 여러 개의 반환이 있는 경우 디버깅할 때 반환에 중단점이나 추적을 붙이기가 더 어렵다는 것입니다.이것은 거의 문제가 되지 않을 뿐이지만, 반환점을 놓치는 것은 괴로운 일입니다.루프 상태와 루프 상단 모두 여전히 독특하기 때문에 루프에서 계속하는 것은 크게 중요하지 않다고 생각합니다.

그 외에 다른 사람들이 하는 말."어떤 것"과 "다른 것"의 상대적인 길이, 중요성 및 가능성에 따라 가장 읽을 수 있는 것을 수행합니다.케이스가 짧고, 사소하며, 가능성이 낮은 케이스일수록 특수 케이스 제어 흐름에 방해가 되지 않습니다.

다른 사람들이 말했듯이, 물건이 짧을 때만 반품/continue을 사용하세요.

개인적으로 다음과 같이 한 줄에 쓸 수 있는 경우에만 계속 사용합니다.

while( loopCondition ) {
    if( innerCondition ) continue;

    //do other stuff
}

코드가 못생겨지지 않고 이렇게 쓸 수 없다면, 만약 / 그렇지 않다면.

grins의 경우 회사 코드베이스 전체에서 "continue;"를 검색하여 사용처를 파악했습니다.하나의 솔루션에서 59개 프로젝트에 걸쳐 695회, 약 1500개의 소스 파일을 사용합니다.

사용되고 있다고 생각하는 주요 방법은 빠른 필터입니다.

foreach (Frobozz bar in foo) {
    if (QuickFilterExclude(bar))
        continue;
    // extensive processing
}

예상 예외에서 복구:

foreach (Frobozz bar in foo) {
    Baz result = new Baz(kDefaultConfiguration);
    try {
        Baz remoteResult = boo.GetConfiguration();
    }
    catch (RemoteConnectionException) {
        continue;
    }
    result.Merge(remoteResult);
    ReportResult(result);
}

그리고 마침내 주 기계에서.

저는 방법이나 루프에서 뛰어내릴 때 할 일이 없기 때문에 일반적으로 if-return 방법을 사용합니다.

상당한 작업이 진행되고 있기 때문에 몸이 길어지면 if-else를 사용하고 #region을 사용하여 블록에 합리적인 이름을 부여하고 사람들이 제어 흐름을 연구할 수 있도록 쉽게 접을 수 있도록 제안합니다.아니면 따로 방법을 만드세요 :)

내 코드에는 다음과 같은 것들이 있었습니다.

    while(){
      boolean intersect = doesIntersect(interval_1,interval_2);
      if(!intersect){
         array.add(interval_2);
         if(// another condition){
            // Do some thing here
         }
         continue;
      }
      // other stuff to do if intersect
    }

거기서 계속 사용해야 할지 다른 을 사용해야 할지 헷갈렸지만 내부 if 조건이 다른 것을 잘 읽을 수 없게 만들 수 있다고 판단하여 계속 사용했습니다.

가독성이 중요하다고 생각합니다!

이해를 돕기 위해 if 문은 두 가지 기본 변형을 허용합니다.

첫 번째 변형:

if (condition)  
{  
    // do stuff if 'condition' is met  
}  
// do other stuff under any condition  

두 번째 변형:

if (condition)  
{  
    // do stuff if 'condition' is met  
} else {  
    // do other stuff if 'condition' isn't met  
}  
  • 제게 있어서 변형 1은 다음을 의미합니다.특정 조건에서 if 문 다음 코드가 수행되기 전에 전처리가 필요합니다. 선택적으로 두 코드 부분 모두 또는 두 번째 코드 부분만 수행됩니다.
  • 그러나 변형 2는 다음을 의미합니다.두 가지 가능성 중 하나가 적용됩니다. 어떤 경우에도 두 코드 파트 모두 수행되지 않습니다.

원래 예제의 "다른 작업 수행" 범주를 직접 결정합니다.

  • "어떤 조건에서도 작업을 수행합니다." 각각 "선택적으로 코드 부분 또는 두 번째 부분만 수행됩니다."
  • "조건'이 충족되지 않으면 작업 수행" 각각 "어떠한 상황에서도 두 코드 부분 모두 수행되지 않습니다."

제 눈에는 분명히 후자의 범주에 속하기 때문에 원래 질문자의 '이전' 코드 변형에 투표합니다.'After' 코드 변형은 코드의 의도된 논리를 위장합니다.독자가 '어떤 일을 하다'를 주의 깊게 분석하지 않으면, 첫 인상은 '다른 일을 하다'가 항상 처리되고 있다는 것인데, 이는 자세히 들여다보면 그렇지 않습니다.의도된 의미에서 프로그래밍 언어의 문을 사용하는 것은 이해할 수 있는 프로그래밍 스타일을 위한 가장 중요한 요구 사항 중 하나인 것 같습니다.

[별도로:Continue를 사용할 때마다 GoTo가 생각납니다. GoTo는 정당한 이유로 친구가 많지 않습니다.]

언급URL : https://stackoverflow.com/questions/963982/should-i-use-return-continue-statement-instead-of-if-else