함수에서 일찍 반환하거나 if 문을 사용해야합니까? [닫은]

나는 종종 이런 종류의 함수를 두 가지 형식으로 작성했으며 한 형식이 다른 형식보다 선호되는지, 왜 그런지 궁금했습니다.

public void SomeFunction(bool someCondition)
{
    if (someCondition)
    {
        // Do Something
    }
}

또는

public void SomeFunction(bool someCondition)
{
    if (!someCondition)
        return;

    // Do Something
}

나는 코딩하는 동안 두뇌가 작동하는 방식이기 때문에 일반적으로 첫 번째 코드로 코딩하지만, 오류 처리를 즉시 처리하고 읽기가 더 쉽기 때문에 두 번째 코드를 선호한다고 생각합니다.

나는 두 번째 스타일을 선호합니다. 적절하게 예외를 끝내거나 예외를 발생시키고, 빈 줄을 넣은 다음 메소드의 "실제"본문을 추가하여 잘못된 사례를 먼저 가져옵니다. 읽는 것이 더 쉽다는 것을 알았습니다.

확실히 후자. 전자는 지금 나쁘게 보이지 않지만 더 복잡한 코드를 얻을 때 아무도 이것을 생각할 수 없다고 생각합니다.

public int SomeFunction(bool cond1, string name, int value, AuthInfo perms)
{
    int retval = SUCCESS;
    if (someCondition)
    {
        if (name != null && name != "")
        {
            if (value != 0)
            {
                if (perms.allow(name)
                {
                    // Do Something
                }
                else
                {
                    reval = PERM_DENY;
                }
            }
            else
            {
                retval = BAD_VALUE;
            }
        }
        else
        {
            retval = BAD_NAME;
        }
    }
    else
    {
        retval = BAD_COND;
    }
    return retval;
}

보다 읽기 쉽다

public int SomeFunction(bool cond1, string name, int value, AuthInfo perms)
{
    if (!someCondition)
        return BAD_COND;

    if (name == null || name == "")
        return BAD_NAME;

    if (value == 0)
        return BAD_VALUE;

    if (!perms.allow(name))
        return PERM_DENY;

    // Do something
    return SUCCESS;
}

나는 단일 출구 지점의 이점을 결코 이해하지 못했음을 인정합니다.

그것은 일반적으로-일반적으로 함수를 조기에 벗어나기 위해 많은 코드를 이동하려고 시도하지 않을 것입니다. 컴파일러는 일반적으로 나를 위해 처리합니다. 그러나 상단에 필요한 기본 매개 변수가 있고 계속 진행할 수 없으면 조기에 나올 것입니다. 마찬가지로, 조건 if이 기능에서 거대한 블록을 생성 하면 그 결과로 조기에 돌파가 발생합니다.

그러나 함수가 호출 될 때 일부 데이터가 필요하면 반환하는 대신 일반적으로 예외 (예 참조)가 발생합니다.

public int myFunction(string parameterOne, string parameterTwo) {
  // Can't work without a value
  if (string.IsNullOrEmpty(parameterOne)) {
    throw new ArgumentNullException("parameterOne");
  } 
  if (string.IsNullOrEmpty(parameterTwo)) {
    throw new ArgumentNullException("parameterTwo");
  }

  // ...      
  // Do some work
  // ...

  return value;
}

나는 일찍 돌아 오는 것을 선호합니다.

하나의 진입 점과 하나의 출구 점이 있으면 항상 머리의 전체 코드를 출구 점까지 추적해야합니다 (다른 코드 조각이 결과에 다른 일을하는지 여부는 알 수 없으므로 존재할 때까지 추적해야합니다). 어떤 분기가 최종 결과를 결정하는지는 중요하지 않습니다. 이것은 따르기가 어렵다.

하나의 항목과 여러 항목이 있으면 결과가있을 때 돌아와서 결과를 추적 할 필요가 없습니다. 메소드 본문을 더 많은 단계로 나누는 것과 같습니다. 각 단계마다 결과를 반환하거나 다음 단계에서 운을 시험해 볼 수 있습니다.

수동으로 정리해야하는 C 프로그래밍에서는 원 포인트 리턴에 대해 언급해야 할 것이 많습니다. 지금 무언가를 정리할 필요가 없더라도 누군가가 함수를 편집하고 무언가를 할당하고 돌아 오기 전에 정리해야 할 수도 있습니다. 그런 일이 발생하면 모든 반환 진술을 살펴 보는 악몽이 될 것입니다.

C ++ 프로그래밍에는 소멸자가 있으며 심지어 스코프 종료 경비원이 있습니다. 코드가 처음부터 예외 안전을 보장하기 위해 이러한 모든 것이 여기에 있어야하므로 코드가 조기 종료로부터 잘 보호되므로 논리적 단점이 없으며 순수하게 스타일 문제입니다.

"최종"블록 코드가 호출되는지 여부와 종료자가 무언가를 보장해야하는 상황을 처리 할 수 ​​있는지 여부에 대해 Java에 대해 충분히 알지 못합니다.

C # 나는 확실히 대답 할 수 없다.

D- 언어는 적절한 내장 스코프 출구 보호대를 제공하므로 조기 퇴장 준비가 잘되어 있으므로 스타일 이외의 문제는 발생하지 않아야합니다.

물론 함수는 처음에는 그리 길지 않아야하며, 거대한 switch 문이 있으면 코드도 잘못 반영됩니다.

승리를위한 초기 수익. 추악한 것처럼 보일 수 있지만 if특히 검사해야 할 여러 조건이있는 경우 큰 래퍼 보다 훨씬 덜 추 합니다.

둘 다 사용합니다.

경우 DoSomething코드의 3-5 라인 인 다음 코드는 최초의 포맷 방법을 사용하여 예쁘다.

그러나 그보다 많은 행이 있으면 두 번째 형식을 선호합니다. 개폐 브래킷이 동일한 화면에 있지 않은 경우가 마음에 들지 않습니다.

단일 엔트리 단일 종료의 고전적인 이유는 그렇지 않으면 공식적인 의미론이 말로 표현할 수 없을 정도로 추악 해지기 때문입니다 (GOTO가 유해한 것으로 간주 된 것과 동일한 이유).

다시 말해, 1 회만 반환하면 소프트웨어가 루틴을 종료 할시기를 쉽게 추론 할 수 있습니다. 또한 예외에 대한 논쟁입니다.

일반적으로 조기 반품 접근법을 최소화합니다.

개인적으로, 나는 처음에 합격 / 불합격 상태 점검을 선호합니다. 이를 통해 함수의 맨 위에 가장 일반적인 실패를 대부분 나머지 로직과 그룹화 할 수 있습니다.

따라 다릅니다.

기능의 나머지 부분을 무의미하게 실행시킬 수있는 명백한 막 다른 데드 엔드 조건이있는 경우 조기 반환. *

함수가 더 복잡하고 그렇지 않으면 여러 개의 종료 점이있을 수있는 경우 Retval + 단일 리턴을 설정하십시오 (가독성 문제).

* 이것은 종종 디자인 문제를 나타낼 수 있습니다. 나머지 코드를 실행하기 전에 많은 메서드가 외부 / 매개 변수 상태 등을 확인해야하는 경우 호출자가 처리해야하는 것일 수 있습니다.

If를 사용하십시오

GOTO에 관한 Don Knuth의 저서에서 나는 그가 가장 가능성이 높은 조건을 if 문에서 항상 우선하는 이유를 읽었습니다. 이것이 여전히 합리적인 아이디어라는 가정하에 (그리고 시대의 속도를 순수하게 고려하지 않는 아이디어). 나는 초기 리턴이 좋은 프로그래밍 관행이 아니라고 말하고 싶습니다. 특히 코드가 실패하지 않는 것보다 실패하지 않는 한 특히 오류 처리에 사용되지 않는다는 사실을 고려할 때 :-)

위의 조언을 따르면 함수의 맨 아래에 해당 반환을 넣어야하며 거기에서 반환을 호출하지 않을 수도 있습니다. 오류 코드를 설정하고 두 줄을 반환하면됩니다. 이에 의해 1 입구 1 출구 이상을 달성한다.

델파이 특정 ...

증거가 없지만 델파이 프로그래머에게는 이것이 좋은 프로그래밍 관행이라는 것을 알고 있습니다. 사전 D2009, 우리가 값을 반환하는 원자 방법이없는, 우리가 exit;하고 result := foo;또는 우리는 단지 예외를 던질 수있다.

대체해야한다면

if (true) {
 return foo;
} 

...에 대한

if true then 
begin
  result := foo; 
  exit; 
end;

당신은 모든 기능의 상단에서 그것을보고 아플 수도 있고 선호합니다.

if false then 
begin
  result := bar;

   ... 
end
else
   result := foo;

그냥 피하십시오 exit.

다음 진술에 동의합니다.

나는 개인적으로 함수의 들여 쓰기를 줄이는 가드 조항의 팬입니다 (두 번째 예). 함수에서 여러 리턴 포인트가 발생하기 때문에 일부 사람들은 마음에 들지 않지만 더 명확하다고 생각합니다.

이 질문에서 stackoverflow 에서 가져 왔습니다 .

나는 요즘 거의 독점적으로 조기 반품을 사용합니다. 나는 이것을 쓴다

self = [super init];

if (self != nil)
{
    // your code here
}

return self;

같이

self = [super init];
if (!self)
    return;

// your code here

return self;

그러나 그것은 정말로 중요하지 않습니다. 함수에 하나 이상의 레벨이 중첩 된 경우 버스트되어야합니다.

나는 쓰는 것을 선호합니다 :

if(someCondition)
{
    SomeFunction();
}

당신처럼, 나는 보통 첫 번째 것을 쓰지만 마지막 것을 선호합니다. 중첩 검사가 많으면 일반적으로 두 번째 방법으로 리팩터링합니다.

오류 처리가 검사에서 어떻게 다른지 좋아하지 않습니다.

if not error A
  if not error B
    if not error C
      // do something
    else handle error C
  else handle error B
else handle error A

나는 이것을 선호한다 :

if error A
  handle error A; return
if error B
  handle error B; return
if error C
  handle error C; return

// do something

상단의 조건을 "전제 조건"이라고합니다. 를 넣으면 if(!precond) return;모든 전제 조건을 시각적으로 나열하게됩니다.

큰 "if-else"블록을 사용하면 들여 쓰기 오버 헤드가 증가 할 수 있습니다 (3 단계 들여 쓰기에 대한 인용문을 잊어 버렸습니다).

if 문을 작게 유지하는 것을 선호합니다.

따라서 다음 중에서 선택하십시오.

if condition:
   line1
   line2
    ...
   line-n

과

if not condition: return

line1
line2
 ...
line-n

"초기 반품"으로 설명한 것을 선택하겠습니다.

나는 당신에게 초기 반품이나 다른 것에 신경 쓰지 않는다. 코드를 단순화하고 if 문의 본문을 단축하는 것을 정말로 좋아한다.

if and for and and 's and is 's 끔찍한 중첩 된 모든 비용을 피하십시오.

다른 사람들이 말했듯이, 그것은 달려 있습니다. 값을 반환하는 작은 함수의 경우 조기 반환을 코딩 할 수 있습니다. 그러나 크기 조정 가능한 함수의 경우 항상 코드에 반환하기 전에 실행될 항목을 넣을 수있는 위치를 알고 싶습니다.

나는 기능 수준에서 실패를 연습합니다. 코드가 일관되고 깨끗하게 유지됩니다 (나와 함께한 사람들에게). 그 때문에 나는 항상 일찍 돌아온다.

종종 확인되는 일부 조건의 경우 AOP를 사용하는 경우 해당 확인에 대한 측면을 구현할 수 있습니다.