OOP의 (단시간) 메소드에서 단 하나의 return 대신 guard 조항을 사용해야한다고 (예 : Martin Fowler) 읽었습니다. 나는 또한 else 절이 가능한 경우 피해야한다는 것을 기억한다.가드 절을 사용하고 else 절을 피하려고합니까?
하지만 내 동료 (나는 3 명으로 구성된 소규모 팀에서 일하고 있음)는 메소드에서 여러 개의 리턴을 사용하지 않도록하고 else 절을 최대한 많이 사용하도록합니다. else 블록.
예를 들어, 한 화면에서 모든 코드를 볼 수 없기 때문에 코딩 스타일을 따르기가 어렵습니다. 그리고 코드를 작성할 때 먼저 가드 절을 작성한 다음 여러 리턴 값을 사용하여 폼으로 변환해야합니다.
내가 잘못했거나 어떻게해야합니까?
이것은 논증 할 만하고 순수한 미학적 인 질문입니다.
조기 반환의 경우 대개 함수의 끝에 배치되는 자원 정리를 놓칠 수 있으므로 조기 회귀는 C 및 유사한 언어에서 역사적으로 피할 수 있습니다.
자바에는 예외가 있으며 try, catch를 사용하면 결국 조기 반환을 두려워 할 필요가 없습니다.
Personality, 나는 자주 당신에게 동의합니다. 왜냐하면 저는 조기 반환을 자주하기 때문에 - 보통 적은 코드와 더 간단한 코드 흐름을 의미합니다.
내 기억이 올바르게 작동한다면 조기 반품을 피하는 또 다른 이유는 이론적으로 코드가 정확한지 쉽게 증명할 수 있다는 것입니다. (a.k.a 형식 검증) – biziclop
+1 논쟁의 여지가 있습니다. 가독성을 위해 조기 반환을 선호합니다. –
나는 대략적으로 가드 절의 형태를 취하고, 많은 헷갈리는'return' 진술을하지 않는 한, 조기 반환을 선호합니다. 예를 들어, for 루프를 깨는 것은 완벽합니다. 'for (Object o : objects) {if (someCondition) {return o; }}' –
http://www.cis.temple.edu/~ingargio/cis71/software/roberts/documents/loopexit.txt을 읽고 마음이 바뀌는 지 확인하십시오. (그들의 생각에는 역사가 있지만 나는 당신과 함께한다.)
편집 : 다음은 기사의 중요한 부분이다. 통제 구조로부터의 단일 출구의 원칙이 원칙적으로 채택되었지만 관측 자료는 채택되지 않았다. 그러나 관측 자료에 따르면 제어 구조를 벗어나는 여러 가지 방법을 허용하면 특정 문제를보다 정확하게 해결할 수 있고 가독성이 떨어지지는 않습니다. 이를 허용하지 않으면 코드가 더 어려워지고 버그가 발생할 가능성이 높아집니다. 이것은 학생부터 교과서 작가까지 다양한 프로그래머에게 적용됩니다. 따라서 적절한 경우 여러 출구를 허용하고 사용해야합니다.
해당 기사를 읽는 데 너무 많습니다. 꼭 필요한 아이디어를 말씀해 주시겠습니까? – HelloWorldNoMore
@HelloWorldNoMore 통제 구조에서 나온 단일 이탈의 원칙이 원칙적으로 채택되었지만 관측 데이터는 채택되지 않았습니다. 그러나 관측 자료에 따르면 제어 구조를 벗어나는 여러 가지 방법을 허용하면 특정 문제를보다 정확하게 해결할 수 있고 가독성이 떨어지지는 않습니다. 이를 허용하지 않으면 코드가 더 어려워지고 버그가 발생할 가능성이 높아집니다. 이것은 학생부터 교과서 작가까지 다양한 프로그래머에게 적용됩니다. 따라서 적절한 경우 여러 출구를 허용하고 사용해야합니다. – btilly
저는 복수 반환/귀가 일찍 캠프에 있습니다. 다른 엔지니어에게이 사실을 확신시키기 위해 로비를 할 것입니다. 커다란 주장을하고 훌륭한 출처를 언급 할 수는 있지만, 결국에는 할 수있는 일은 피치를 만들고, 타협을 제안하고, 결정을 내리고, 팀으로 일한다는 것입니다. (주제의 재 방문은 의문의 여지가 없습니다.)
이것은 정말로 스타일에 달려 있으며, 사물의 거대한 계획에서, 비교적 사소한 것입니다. 전반적으로 어느 스타일에도 적응할 수 있다면 더 효과적인 개발자입니다. 이것이 정말로 "코딩 스타일을 따르기가 어렵다"면, 결국에는 더 나은 엔지니어가 끝나기 때문에 작업하라고 제안합니다.
나는 한 번 엔지니어에게 내게 와서 자신의 코딩 스타일을 따르기 위해 경륜의 시대를 가졌다고 주장했다. 그는 확립 된 코딩 스타일이 눈을 해치고 집중하기가 어려웠다 고 말했습니다. (나는 그가 "메스 꺼운"이라고 말한 것조차도 생각할 것입니다.) 나는 그에게 만약 그가 많은 사람들의 코드를 다루기 만한다면, 그는 썼으며 그 반대도 마찬가지였다. 그가 동의 한 스타일로 작업하는 데 적응할 수 없다면, 나는 그를 사용할 수 없었고 아마도이 유형의 공동 작업 프로젝트가 그에게 적합한 장소가 아니었을 것입니다. 우연히도 모든 코드 검토가 여전히 전투 였지만 그 이후에는 문제가 적었습니다.
가드 절은 현재 방법이 특정 경우에 관심이 없다는 것을 명확하게 나타 내기 때문에 좋은 생각입니다. 메서드의 맨 처음에 일부 사례 (예 : 일부 값이 0보다 작은 경우)를 처리하지 못하도록 정리하면 메서드의 나머지 부분은 해당 책임을 순수하게 구현하는 것입니다.
가드 절이 한 가지 더 강력한 경우입니다. 일부 인수가 받아 들여지지 않을 때 입력을 검증하고 예외를 던지는 구문입니다. 없는. 이 경우 실행을 진행하고 싶지는 않지만 메소드의 맨 처음 부분에 던지고 싶습니다. 예외를 던지는 로직과 구현중인 메소드의 핵심을 섞어서는 안되기 때문에 가드 절이 최상의 솔루션입니다.
예외를 throw하는 guard 절에 대해 이야기 할 때 C#에서 확장 메서드를 사용하여 간소화 할 수있는 방법에 대한 기사가 있습니다 (How to Reduce Cyclomatic Complexity: Guard Clause). 이 메서드는 Java에서는 사용할 수 없지만 C#에서는 유용합니다.
_ "한 화면에서 모든 메소드 코드를 볼 수 없습니다."_ 그렇다면 코드가 너무 많이 들여져 코드의 오른쪽 가장자리 바깥 쪽을 차지하게되었습니다. 화면? 또는 if-else가 조금 더 많은 공간을 차지하므로 메소드가 길어야합니다 (키가 큽니다). B.t.w. 나는 가드 조항을 좋아한다. – KajMagnus
* "else 블록에 주석 행이 하나만있는 경우에도"* -이 코드 소스 중 하나는 코드 완료입니다. 그들이 그것을 적용하는 것에 관해 너무 독단적 인 것처럼 그것은 들린다. – icc97