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

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 참조 사용으로부터 안전합니다.

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

---

Bad practice??? No way. In fact, it is always better to handle validations by returning from the method at the earliest if validations fail. Else it would result in huge amount of nested ifs & elses. Terminating early improves code readability.

Also check the responses on a similar question: Should I use return/continue statement instead of if-else?

---

It's not bad practice (for all reasons already stated). However, the more returns you have in a method, the more likely it should be split into smaller logical methods.

---

The first example is using a guard statement. From Wikipedia:

In computer programming, a guard is a boolean expression that must evaluate to true if the program execution is to continue in the branch in question.

I think having a bunch of guards at the top of a method is a perfectly understandable way to program. It is basically saying "do not execute this method if any of these are true".

So in general it would like this:

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

  DoThat();
}

I think that's a lot more readable then:

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

---

There is no performance penalty, however the second piece of code is more readable and hence easier to maintain.

---

It's perfectly okay and no 'performance penalty', but never ever write an 'if' statement without brackets.

Always

if( foo ){
    return;
}

It's way more readable; and you'll never accidentally assume that some parts of the code are within that statement when they're not.

---

In this case, your second example is better code, but that has nothing to do with returning from a void function, it's simply because the second code is more direct. But returning from a void function is entirely fine.

---

I'm going to disagree with all you young whippersnappers on this one.

Using return in the middle of a method, void or otherwise, is very bad practice, for reasons that were articulated quite clearly, nearly forty years ago, by the late Edsger W. Dijkstra, starting in the well-known "GOTO Statement Considered Harmful", and continuing in "Structured Programming", by Dahl, Dijkstra, and Hoare.

The basic rule is that every control structure, and every module, should have exactly one entry and one exit. An explicit return in the middle of the module breaks that rule, and makes it much harder to reason about the state of the program, which in turn makes it much harder to say whether the program is correct or not (which is a much stronger property than "whether it appears to work or not").

"GOTO Statement Considered Harmful" and "Structured Programming" kicked off the "Structured Programming" revolution of the 1970s. Those two pieces are the reasons we have if-then-else, while-do, and other explicit control constructs today, and why GOTO statements in high-level languages are on the Endangered Species list. (My personal opinion is that they need to be on the Extinct Species list.)

It is worth noting that the Message Flow Modulator, the first piece of military software that EVER passed acceptance testing on the first try, with no deviations, waivers, or "yeah, but" verbiage, was written in a language that did not even have a GOTO statement.

It is also worth mentioning that Nicklaus Wirth changed the semantics of the RETURN statement in Oberon-07, the latest version of the Oberon programming language, making it a trailing piece of the declaration of a typed procedure (i.e., function), rather than an executable statement in the body of the function. His explication of the change said that he did it precisely because the previous form WAS a violation of the one-exit principle of Structured Programming.

---

Throw exception instead of returning nothing when object is null etc.

Your method expects object to be not null and is not the case so you should throw exception and let caller handle that.

But early return is not bad practice otherwise.

참고URL : https://stackoverflow.com/questions/1283325/is-it-bad-practice-to-use-return-inside-a-void-method