void 메서드 내에서 return을 사용하는 것이 나쁜 습관입니까?

다음 코드를 상상해보십시오.

void DoThis()
{
    if (!isValid) return;

    DoThat();
}

void DoThat() {
    Console.WriteLine("DoThat()");
}

void 메서드 내에서 반환을 사용해도 괜찮습니까? 성능 저하가 있습니까? 또는 다음과 같은 코드를 작성하는 것이 좋습니다.

void DoThis()
{
    if (isValid)
    {
        DoThat();
    }
}

void 메서드의 반환은 나쁘지 않으며 중첩을 줄이기 위해 문을 반전if 하는 일반적인 관행 입니다.

그리고 메소드에 대한 중첩이 적 으면 코드 가독성과 유지 보수성이 향상됩니다.

실제로 return 문이없는 void 메서드가있는 경우 컴파일러는 항상 마지막에 ret 명령어 를 생성 합니다.

가드를 사용하는 또 다른 큰 이유가 있습니다.

중히 여기다:

void MyFunc(object obj)
{
    if (obj != null)
    {
        obj.DoSomething();
    }
}

대:

void MyFunc(object obj)
{
    if (obj == null)
        return;

    obj.DoSomething();
}

이제 다른 프로그래머가 다음 행을 추가한다고 상상해보십시오. obj.DoSomethingElse ();

void MyFunc(object obj)
{
    if (obj != null)
    {
        obj.DoSomething();
    }

    obj.DoSomethingElse();
}

void MyFunc(object obj)
{
    if (obj == null)
        return;

    obj.DoSomething();
    obj.DoSomethingElse();
}

분명히 이것은 단순한 경우이지만 프로그래머는 첫 번째 (중첩 된 코드) 인스턴스에서 프로그램에 충돌을 추가했습니다. 두 번째 예제 (가드가있는 조기 종료)에서 가드를 통과하면 코드가 의도하지 않은 null 참조 사용으로부터 안전합니다.

물론 훌륭한 프로그래머는 이런 실수를하지 않습니다. 그러나 예방이 치료보다 낫습니다.이 잠재적 인 오류 소스를 완전히 제거하는 방식으로 코드를 작성할 수 있습니다. 중첩은 복잡성을 추가하므로 모범 사례에서는 중첩을 줄이기 위해 코드를 리팩토링하는 것이 좋습니다.

나쁜 연습 ??? 절대 안돼. 사실, 유효성 검사가 실패하면 가장 빨리 메서드에서 반환하여 유효성 검사를 처리하는 것이 항상 더 좋습니다. 그렇지 않으면 엄청난 양의 중첩 된 if 및 else가 발생합니다. 일찍 종료하면 코드 가독성이 향상됩니다.

또한 유사한 질문에 대한 응답을 확인하십시오. if-else 대신 return / continue 문을 사용해야합니까?

나쁜 습관은 아닙니다 (이미 언급 된 모든 이유로). 그러나 메서드에서 더 많은 수익을 얻을수록 더 작은 논리적 메서드로 분할되어야합니다.

첫 번째 예는 가드 문을 사용하는 것입니다. 에서 위키 백과 :

컴퓨터 프로그래밍에서 가드는 해당 분기에서 프로그램 실행을 계속하려면 true로 평가해야하는 부울 식입니다.

메서드 맨 위에 많은 경비원을 두는 것이 완벽하게 이해할 수있는 프로그래밍 방법이라고 생각합니다. 기본적으로 "이 중 하나라도 사실이면이 메서드를 실행하지 마십시오"라고 말합니다.

따라서 일반적으로 다음과 같습니다.

void DoThis()
{
  if (guard1) return;
  if (guard2) return;
  ...
  if (guardN) return;

  DoThat();
}

나는 그것이 훨씬 더 읽기 쉽다고 생각합니다.

void DoThis()
{
  if (guard1 && guard2 && guard3)
  {
    DoThat();
  }
}

성능 저하는 없지만 두 번째 코드는 더 읽기 쉽고 유지 관리가 더 쉽습니다.

이 경우 두 번째 예제는 더 나은 코드이지만 void 함수에서 반환하는 것과 관련이 없습니다. 두 번째 코드가 더 직접적이기 때문입니다. 그러나 void 함수에서 반환하는 것은 전적으로 괜찮습니다.

완벽하게 괜찮고 '성능 저하'는 없지만 대괄호없이 'if'문을 작성하지 마십시오.

항상

if( foo ){
    return;
}

훨씬 더 읽기 쉽습니다. 그리고 코드의 일부가 그렇지 않은 경우 해당 명령문 내에 있다고 우연히 가정하지 않을 것입니다.

나는 이것에 대한 당신의 모든 젊은 whippersnappers에 동의하지 않을 것입니다.

방법의 중간에 반환을 사용하는 것은 매우 나쁜 습관입니다. ", Dahl, Dijkstra 및 Hoare의"구조적 프로그래밍 "에서 계속됩니다.

기본 규칙은 모든 제어 구조와 모든 모듈에 정확히 하나의 입구와 출구가 있어야한다는 것입니다. 모듈 중간에 명시 적으로 반환하면 해당 규칙이 위반되고 프로그램 상태에 대해 추론하기가 훨씬 더 어려워 져 프로그램이 올바른지 여부를 말하기가 훨씬 더 어려워집니다 (이는 훨씬 더 강력한 속성입니다. "작동 여부"보다).

"GOTO 문은 유해한 것으로 간주 됨"및 "구조적 프로그래밍"이 1970 년대의 "구조적 프로그래밍"혁명을 시작했습니다. 이 두 부분은 오늘날 우리가 if-then-else, while-do 및 기타 명시 적 제어 구조를 가지고있는 이유와 고수준 언어의 GOTO 문이 멸종 위기에 처한 종 목록에있는 이유입니다. (내 개인적인 의견은 그들이 멸종 종 목록에 있어야한다는 것입니다.)

첫 번째 시도에서 허용 테스트를 통과 한 최초의 군사 소프트웨어 인 Message Flow Modulator는 편차, 면제 또는 "예,하지만"말이없는 언어로 작성되었다는 점은 주목할 가치가 있습니다. GOTO 문.

또한 Nicklaus Wirth가 Oberon 프로그래밍 언어의 최신 버전 인 Oberon-07에서 RETURN 문의 의미를 변경하여 형식화 된 프로 시저 (즉, 함수) 선언의 후행 부분이되었음을 언급 할 가치가 있습니다. 함수 본문의 실행 가능한 문. 변화의 그의 해설은 이전의 형태 때문에 그가 정확하게 해냈다 고 말했다 WAS 구조화 프로그래밍의 한 출구 원칙의 위반.

경비원을 사용하는 동안 독자를 혼동하지 않도록 특정 지침을 따르십시오.

• 함수 는 한 가지를 수행합니다.
• 가드는 함수 의 첫 번째 논리 로만 도입됩니다.
• 중첩되지 부분은 함수의 포함 핵심 의도를

예

// guards point you to the core intent
void Remove(RayCastResult rayHit){

  if(rayHit== RayCastResult.Empty)
    return
    ;
  rayHit.Collider.Parent.Remove();
}

// no guards needed: function split into multiple cases
int WonOrLostMoney(int flaw)=>
  flaw==0 ? 100 :
  flaw<10 ? 30 :
  flaw<20 ? 0 :
  -20
;

객체가 null 인 경우 아무것도 반환하지 않고 예외를 throw합니다.

귀하의 메서드는 객체가 null이 아닐 것으로 예상하고 케이스가 아니므로 예외를 throw하고 호출자가 처리하도록해야합니다.

그러나 조기 복귀는 그렇지 않으면 나쁜 습관이 아닙니다.