루비의 리턴 포인트는 무엇입니까?


79

return다음과 같은 변수를 넣는 것의 차이점은 무엇입니까?

돌아 오지 않음

def write_code(number_of_errors)
  if number_of_errors > 1
     mood = "Ask me later"
  else
     mood = "No Problem"
  end  
  mood
end

반환

def write_code(number_of_errors)
  if number_of_errors > 1
    mood =  "Ask me later"
  else
    mood = puts "No Problem"
  end  
  return mood
end

답변:


118

return 당신이 일찍 탈옥 할 수있게합니다 :

def write_code(number_of_errors)
  return "No problem" if number_of_errors == 0
  badness = compute_badness(number_of_errors)
  "WHAT?!  Badness = #{badness}."
end

경우 number_of_errors == 0, 다음 "No problem"즉시 반환됩니다. 그러나 방법의 끝에서 관찰 한 것처럼 불필요합니다.


편집 :return 즉시 종료 되는 것을 보여주기 위해 다음 기능을 고려하십시오.

def last_name(name)
  return nil unless name
  name.split(/\s+/)[-1]
end

이 함수를로 호출하면 last_name("Antal S-Z")을 반환 "S-Z"합니다. 로 호출하면을 last_name(nil)반환합니다 nil. 경우 return 하지 않았다 중단 즉시, 그것을 실행하려고 할 nil.split(/\s+/)[-1]오류가 발생 것이다.


좋아요, 좋은 예입니다. 따라서 return은 반환 값을 저장하지만 나머지 메서드는 실행됩니다. 그것을 사용하기를 기다릴 수 없습니다.
thenengah

4
아니요, 반대의 경우 : return 즉시 메서드를 종료합니다. 그 예에 대해 생각해 보면 모든 것이 정상이라는 것을 안다면 나쁜 점을 계산하는 것이 유용하지 않을 것입니다. 더 명확하게 답변을 편집하겠습니다.
Antal Spector-Zabusky 2011 년

8
return, break등을 매개 변수없이 사용할 수 있습니다 nil. 기본적으로 반환 됩니다.
Nakilon 2011 년

38

Ruby가 마지막으로 평가 된 표현식을 자동으로 반환하므로 메서드에서 실행될 마지막 줄인 경우 "return"을 사용할 필요가 없습니다.

최종 "분위기"도 필요하지 않으며 IF 문에서 이러한 할당이 필요하지 않습니다.

def write_code(number_of_errors)
    if number_of_errors > 1
       "ERROR"
    else
       "No Problem"
    end  
end

puts write_code(10)

산출:

오류


37
비 루비 배경에서 나온 결과물은 확실히 WTF입니다. :)
Patrick

return은 실행을 일찍 종료 할 수 있습니다.
Joe.wang 2014

1
Return은 마지막으로 평가 된 표현식 대신 nil을 반환하는 메서드를 갖는데도 유용 할 수 있으므로 메서드 끝에 인수가없는 반환이 표시되는 경우도 있습니다.
garythegoat

1
@garythegoat : 또는 간단히 nil.
Karoly Horvath

4

목록을 살펴볼 때 return을 사용하고 목록의 구성원이 기준을 충족하면 함수를 종료하고 싶습니다. 다음과 같은 단일 문으로이를 수행 할 수 있습니다.

list.select{|k| k.meets_criteria}.length == 0

어떤 상황에서는

list.each{|k| return false if k.meets_criteria}

제가 생각하기에 유연성이 추가 된 한 줄입니다. 예를 들어, 첫 번째 예제는 이것이 메소드의 유일한 라인이고 우리는 어떤 일이 있어도이 지점에서 돌아오고 싶다고 가정합니다. 그러나 이것이 나머지 메서드를 진행하는 것이 안전한지 여부를 확인하는 테스트 인 경우 첫 번째 예제에서는 다른 방식으로 처리해야합니다.

편집하다:

유연성을 추가하려면 다음 코드 줄을 고려하십시오.

list_of_method_names_as_symbols.each{|k| list_of_objects.each{|j| return k if j.send(k)}}

나는 이것이 없이도 한 줄로 성취 될 수 있다고 확신 return하지만, 머리 꼭대기에서 나는 방법을 알지 못합니다.

그러나 이것은 이제 부울 메서드 목록과 해당 메서드를 구현하는 개체 목록을 사용하여 호출 할 수있는 상당히 유연한 코드 줄입니다.

편집하다

이 줄은 블록이 아닌 메서드 내부에 있다고 가정합니다.


그러나 이것은 대부분 문체적인 선택이며, 대부분의 상황에서 return.


break이 경우 훨씬 더 유용합니다.
Nakilon 2011 년

4

루비는 항상 돌아옵니다! 가장 좋은 방법은

def write_code(number_of_errors)
  (number_of_errors > 1)? "ERROR" : "No Problem"
end

number_of_errors> 1이면 ERROR를 반환하고 그렇지 않으면 문제 없음을 의미합니다.


3

그것의 멋진 루비는 명시 적으로 return 문을 지정하지 않는이 좋은 기능을 제공하지만 프로그래밍 표준으로서 항상 필요할 때마다 "return"문을 지정하려고 노력해야한다고 생각합니다. 이것은 C ++, Java, PHP 등과 같은 다른 배경에서 왔고 루비를 배우는 사람이 코드를 더 읽기 쉽게 만드는 데 도움이됩니다. "return"문은 아무런 해를 끼치 지 않으므로 함수에서 반환하는 기존 방식과 더 표준적인 방법을 건너 뛰는 이유는 무엇입니까?


4
"그렇다면 함수에서 복귀하는 관습적이고보다 표준적인 방법을 건너 뛰는 이유"← Ruby 에서는 생략 return 관습적인 표준 이기 때문 입니다 . return스타일이 좋은 Ruby 코드가 보이면 조기에 . 한 언어에서 다른 언어로 코드 스타일 규칙을 적용하려고하면 숙련 된 프로그래머를 온 보딩하고 자신의 코드 스타일을 일관되게 유지하기가 더 어려워집니다.
David Moles 2015 년

난 여전히 자신이 라인의 끝에 세미콜론을 넣어 잡아
gdbj

루비의 선에서 2 위, "암시적인 것이 명시적인 것보다 낫다"아닌가? ;-)
Mark

1

다른 언어에서 온 사람들에 대한 작은주의 사항입니다. OP와 같은 함수가 있고 "마지막 계산 된"규칙을 사용하여 반환 값을 자동으로 설정한다고 가정합니다.

def write_code(number_of_errors)
  if number_of_errors > 1
     mood = "Ask me later"
  else
     mood = "No Problem"
  end  
end

디버깅 (또는 로깅) 문을 추가한다고 가정 해 보겠습니다.

def write_code(number_of_errors)
  if number_of_errors > 1
     mood = "Ask me later"
  else
     mood = "No Problem"
  end  
  puts "### mood = #{mood}"
end

이제 무엇을 추측하십시오. puts이제는 함수의 반환 값이되는 nil을 반환 하므로 코드가 손상되었습니다 .

해결책은 OP가 한 것처럼 항상 마지막 줄에 반환 값을 명시 적으로 넣는 습관을 갖는 것입니다.

def write_code(number_of_errors)
  if number_of_errors > 1
     mood = "Ask me later"
  else
     mood = "No Problem"
  end  
  puts "### mood = #{mood}"
  mood
end

-1

의 Unnecesarity return기능의 마지막 줄에서 단지입니다 syntaxic 설탕 루비. 대부분의 절차 언어 return에서 각 함수 (C ++에서는 void가 아님) 를 작성해야 합니다.


3
나는 그것을 통사론 적 설탕이라고 부르지 않을 것입니다. 여기서 핵심 특징은 거의 모든 것이 표현이라는 것 입니다. if문, 문 블록. 그것이이 표현력을 허용하는 것입니다.
Karoly Horvath

나는 Karoly의 의견에 동의합니다. 모든 것이 표현이기 때문에 통사론적인 설탕이 아닙니다.
fatuhoku
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.