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


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.