가독성과 효율성을 잃기 때문에 단일 종료점 함수가 코딩에 나쁜 방법이라고 항상 들었습니다. 나는 아무도 반대편을 주장하는 것을 들어 본 적이 없습니다.
나는 이것이 CS와 관련이 있다고 생각했지만이 질문은 cstheory stackexchange에서 떨어졌습니다.
가독성과 효율성을 잃기 때문에 단일 종료점 함수가 코딩에 나쁜 방법이라고 항상 들었습니다. 나는 아무도 반대편을 주장하는 것을 들어 본 적이 없습니다.
나는 이것이 CS와 관련이 있다고 생각했지만이 질문은 cstheory stackexchange에서 떨어졌습니다.
답변:
생각에는 여러 학파가 있으며 주로 개인적 선호도에 달려 있습니다.
하나는 출구 지점이 하나뿐이면 덜 혼란 스럽습니다. 메소드를 통해 단일 경로가 있고 출구를 찾을 위치를 알고 있습니다. 마이너스 쪽에서 들여 쓰기를 사용하여 중첩을 표시하면 코드가 오른쪽으로 크게 들여 쓰기되어 모든 중첩 범위를 따르는 것이 매우 어려워집니다.
또 다른 방법은 전제 조건을 확인하고 메서드 시작시 일찍 종료 할 수 있으므로 메서드 본문 전체가 오른쪽으로 5 마일 떨어져 들여 쓰기되지 않고 특정 조건이 참임을 메서드 본문에서 알 수 있다는 것입니다. 이는 일반적으로 걱정해야하는 범위의 수를 최소화하므로 코드를 훨씬 쉽게 따라갈 수 있습니다.
세 번째는 원하는 곳 어디에서나 나갈 수 있다는 것입니다. 예전에는 더 혼란 스러웠지만 이제는 도달 할 수없는 코드를 감지하는 구문 색상 편집기와 컴파일러가 있으므로 처리하기가 훨씬 쉽습니다.
나는 중간 캠프에 있습니다. 단일 종료 지점을 적용하는 것은 무의미하거나 심지어 비생산적인 제한입니다. 실행. 그러나 방법을 "게이팅"하면 방법 본문을 크게 단순화 할 수 있습니다.
singe exit패러다임 에서 딥 네 스팅은 go to문장의 섬세함 으로 제거 될 수 있습니다 . 또한 함수의 로컬 Error레이블 아래에서 일부 후 처리를 수행 할 수있는 기회를 얻습니다. 이는 여러 returns 로는 불가능 합니다.
일반적인 권장 사항은 return 문이 가능한 경우 부작용이있는 첫 번째 코드 앞이나 부작용이있는 마지막 코드 뒤에 위치해야한다는 것입니다. 나는 다음과 같은 것을 고려할 것입니다.
if (! argument) // null이 아닌지 확인
return ERR_NULL_ARGUMENT;
... 널이 아닌 인수 처리
만약 (OK)
반환 0;
그밖에
반환 ERR_NOT_OK;
보다 명확 :
int return_value;
if (argument) // 널이 아님
{
.. 널이 아닌 인수 처리
.. 결과를 적절하게 설정
}
그밖에
결과 = ERR_NULL_ARGUMENT;
반환 결과;
특정 조건으로 인해 함수가 어떤 작업도 수행하지 못하도록해야하는 경우 함수가 어떤 작업을 수행 할 수있는 지점보다 높은 지점에서 함수에서 일찍 복귀하는 것을 선호합니다. 함수가 부작용이있는 작업을 수행 한 후에는 모든 부작용을 처리해야 함을 명확히하기 위해 바닥에서 돌아 오는 것을 선호합니다.
ok변수를 관리하는 첫 번째 예 는 나에게 단일 반환 방식으로 보입니다. 또한 if-else 블록은 다음과 같이 간단히 다시 작성할 수 있습니다.return ok ? 0 : ERR_NOT_OK;
return모든 것을 수행하는 모든 코드 앞에 시작 부분이 있습니다. ?:연산자 사용과 관련 하여 별도의 줄에 작성하면 많은 IDE에서 디버그 중단 점을 비정상 시나리오에 쉽게 연결할 수 있습니다. BTW, "단일 종료점" 의 진짜 열쇠는 중요한 것은 정상 함수에 대한 각각의 특정 호출에 대해 종료 점이 호출 직후의 지점 이라는 것을 이해하는 데 있습니다 . 요즘 프로그래머들은 그것을 당연한 것으로 여기지만 항상 그런 것은 아닙니다. 드물게 코드가 스택 공간없이
단일 진입 점과 출구 점은 구조화 된 프로그래밍과 단계별 스파게티 코딩의 원래 개념이었습니다. 변수에 할당 된 메모리 공간을 적절하게 정리해야하므로 여러 종료점 함수에 더 많은 코드가 필요하다는 믿음이 있습니다. 함수가 변수 (리소스)를 할당하고 적절한 정리없이 조기에 함수에서 나가면 리소스 누수가 발생하는 시나리오를 고려하십시오. 또한 모든 종료 전에 정리를 구성하면 많은 중복 코드가 생성됩니다.
대부분의 경우 결과물의 요구에 따라 결정됩니다. "예전에는"여러 반환 지점이있는 스파게티 코드가 메모리 누수를 유발했습니다. 그 방법을 선호하는 코더는 일반적으로 잘 정리되지 않았기 때문입니다. 또한 일부 컴파일러가 중첩 된 범위에서 반환하는 경우 반환 중에 스택이 팝될 때 반환 변수에 대한 참조를 "손실"하는 문제가있었습니다. 보다 일반적인 문제는 함수의 호출 상태가 반환 상태와 정확히 동일하도록 시도하는 재진입 코드입니다. oop의 돌연변이가 이것을 위반했고 개념은 보류되었습니다.
여러 출구 지점이 제공하는 속도가 필요한 결과물, 특히 커널이 있습니다. 이러한 환경에는 일반적으로 자체 메모리 및 프로세스 관리 기능이 있으므로 누수 위험이 최소화됩니다.
개인적으로 단일 종료 지점을 갖는 것을 좋아합니다. 종종이를 사용하여 return 문에 중단 점을 삽입하고 코드가 해당 솔루션을 결정하는 방법에 대한 코드 검사를 수행하기 때문입니다. 나는 단지 입구로 가서 단계를 통과 할 수 있으며, 광범위하게 중첩되고 재귀적인 솔루션을 사용합니다. 코드 검토 자로서 함수의 다중 반환에는 훨씬 더 깊은 분석이 필요합니다. 따라서 구현 속도를 높이기 위해 수행하는 경우 Peter를 강탈하여 Paul을 구하는 것입니다. 코드 검토에 더 많은 시간이 필요하므로 효율적인 구현에 대한 가정이 무효화됩니다.
-2 센트
자세한 내용은이 문서를 참조하십시오 : NISTIR 5459
multiple returns in a function requires a much deeper analysis함수가 이미 큰 경우에만 (> 1 화면), 그렇지 않으면 분석이 더 쉬워집니다
제 생각에는 한 지점에서만 함수 (또는 다른 제어 구조)를 종료하라는 조언이 종종 과매도되었습니다. 일반적으로 한 지점에서만 나가는 이유는 두 가지입니다.
두 번째 이유는 미묘하고 특히 함수가 큰 데이터 구조를 반환하는 경우 장점이 있습니다. 그러나 나는 그것에 대해 너무 걱정하지 않을 것입니다.
학생이라면 수업에서 최고 점수를 받고 싶습니다. 강사가 선호하는 것을하십시오. 그는 아마도 그의 관점에서 타당한 이유가있을 것입니다. 그래서 최소한 그의 관점을 배울 것입니다. 이것은 그 자체로 가치가 있습니다.
행운을 빕니다.
나는 단일 출구 스타일의 옹호자였습니다. 내 추론은 대부분 고통에서 비롯되었습니다 ...
단일 종료는 디버그하기가 더 쉽습니다.
오늘날 우리가 가지고있는 기술과 도구를 감안할 때 단위 테스트 및 로깅으로 인해 단일 종료가 불필요하게 될 수 있으므로 이것은 훨씬 덜 합리적인 입장입니다. 즉, 디버거에서 코드가 실행되는 것을 관찰해야 할 때 여러 종료 지점이 포함 된 코드를 이해하고 작업하는 것이 훨씬 더 어려웠습니다.
이것은 상태를 검사하기 위해 할당을 삽입해야 할 때 특히 그렇습니다 (최신 디버거에서 watch 표현식으로 대체 됨). 문제를 숨기거나 실행을 완전히 중단시키는 방식으로 제어 흐름을 변경하는 것도 너무 쉬웠습니다.
단일 종료 방법은 디버거에서 단계를 진행하기 쉬웠고 논리를 깨지 않고 분리하기가 더 쉬웠습니다.
대답은 상황에 따라 매우 다릅니다. GUI를 만들고 API를 초기화하고 메인 시작시 창을 여는 함수가있는 경우 오류를 발생시킬 수있는 호출로 가득 차게되며, 각 호출로 인해 프로그램 인스턴스가 닫힙니다. 중첩 된 IF 문을 사용하고 들여 쓰기하면 코드가 오른쪽으로 매우 치우칠 수 있습니다. 각 단계에서 오류를 반환하는 것이 코드에 몇 개의 플래그를 사용하여 디버그하는 것만큼이나 쉬우면서 더 좋고 실제로 더 읽기 쉬울 수 있습니다.
그러나 다른 조건을 테스트하고 메서드의 결과에 따라 다른 값을 반환하는 경우 단일 종료 지점을 사용하는 것이 훨씬 더 좋습니다. 저는 MATLAB에서 매우 커질 수있는 이미지 처리 스크립트 작업을했습니다. 여러 개의 종료 점이 코드를 따라 가기 어렵게 만들 수 있습니다. Switch 문이 훨씬 더 적절했습니다.
가장 좋은 방법은 당신이가는 동안 배우는 것입니다. 무언가에 대한 코드를 작성하는 경우 다른 사람의 코드를 찾아서 구현 방법을 확인하십시오. 좋아하는 비트와 싫어하는 비트를 결정하십시오.
함수에 여러 개의 종료 점이 필요하다고 생각되면 함수가 너무 커서 너무 많은 작업을 수행하는 것입니다.
Robert C. Martin의 저서 Clean Code에서 함수에 대한 장을 읽는 것이 좋습니다.
기본적으로 4 줄 이하의 코드로 함수를 작성해야합니다.
Mike Long의 블로그 에서 몇 가지 메모 :