É bom estilo retornar explicitamente em Ruby?

Vindo de um background em Python, onde sempre existe uma "maneira certa de fazer" (uma maneira "Pythonic") quando se trata de estilo, estou me perguntando se o mesmo existe para Ruby. Eu tenho usado minhas próprias diretrizes de estilo, mas estou pensando em liberar meu código-fonte e gostaria que ele seguisse as regras não escritas que possam existir.

É "The Ruby Way" digitar explicitamente returnmétodos? Eu já vi isso com e sem, mas existe uma maneira certa de fazê-lo? Existe talvez um momento certo para fazê-lo? Por exemplo:

def some_func(arg1, arg2, etc)
  # Do some stuff...
  return value # <-- Is the 'return' needed here?
end

Pergunta antiga (e "respondida"), mas colocarei meus dois centavos como resposta.

TL; DR - Você não precisa, mas pode tornar seu código muito mais claro em alguns casos.

Embora não usar um retorno explícito possa ser "o caminho do Ruby", é confuso para programadores que trabalham com código desconhecido ou não familiarizado com esse recurso do Ruby.

É um exemplo um tanto artificial, mas imagine ter uma pequena função como essa, que adiciona uma ao número passado e a atribui a uma variável de instância.

def plus_one_to_y(x)
    @y = x + 1
end

Isso deveria ser uma função que retornou um valor ou não? É realmente difícil dizer o que o desenvolvedor quis dizer, pois atribui a variável de instância E retorna o valor atribuído também.

Suponha que, muito mais tarde, outro programador (talvez não familiarizado com o modo como o Ruby retorna com base na última linha de código executada) apareça e deseje colocar algumas instruções de impressão para registro, e a função se torne essa ...

def plus_one_to_y(x)
    @y = x + 1
    puts "In plus_one_to_y"
end

Agora a função está quebrada se algo espera um valor retornado . Se nada espera um valor retornado, tudo bem. Claramente, se em algum lugar mais abaixo da cadeia de código, algo chamando isso de espera de um valor retornado, ele falhará, pois não receberá de volta o que espera.

A verdadeira questão agora é esta: algo realmente esperava um valor retornado? Isso quebrou alguma coisa ou não? Será que vai quebrar algo no futuro? Quem sabe! Somente uma revisão completa do código de todas as chamadas informará você.

Portanto, para mim, pelo menos, a abordagem da melhor prática é ser muito explícito que você está retornando algo, se for o caso, ou não devolve nada quando isso não acontece.

Portanto, no caso de nossa pequena função de demonstração, supondo que desejássemos retornar um valor, seria escrito assim ...

def plus_one_to_y(x)
    @y = x + 1
    puts "In plus_one_to_y"
    return @y
end

E seria muito claro para qualquer programador que ele retornasse um valor, e muito mais difícil para eles quebrá-lo sem perceber.

Como alternativa, pode-se escrever assim e deixar de fora a declaração de retorno ...

def plus_one_to_y(x)
    @y = x + 1
    puts "In plus_one_to_y"
    @y
end

Mas por que se preocupar em deixar de fora a palavra retorno? Por que não colocá-lo lá e deixar 100% claro o que está acontecendo? Literalmente, não terá impacto na capacidade de execução do seu código.

Não. O bom estilo Ruby geralmente usaria apenas retornos explícitos para um retorno antecipado . Ruby é especialista em minimalismo de código / magia implícita.

Dito isto, se um retorno explícito tornar as coisas mais claras ou mais fáceis de ler, não prejudicará nada.

Pessoalmente, uso a returnpalavra-chave para distinguir entre o que chamo de métodos funcionais , ou seja, métodos executados principalmente por seu valor de retorno e métodos processuais executados principalmente por seus efeitos colaterais. Portanto, métodos nos quais o valor de retorno é importante, obtenha uma returnpalavra-chave extra para chamar a atenção para o valor de retorno.

Uso a mesma distinção ao chamar métodos: métodos funcionais obtêm parênteses, métodos processuais não.

E por último, mas não menos importante, também uso essa distinção com blocos: blocos funcionais recebem chaves, blocos de procedimentos (ou seja, blocos que "fazem" alguma coisa) recebem do/ end.

No entanto, tento não ser religioso: com blocos, chaves e do/ / endtem precedência diferente e, em vez de adicionar parênteses explícitos para desambiguar uma expressão, apenas mudo para o outro estilo. O mesmo vale para a chamada de método: se adicionar parênteses em torno da lista de parâmetros torna o código mais legível, eu o faço, mesmo que o método em questão seja de natureza processual.

Na verdade, o importante é distinguir entre:

1. Funções - métodos executados pelo valor de retorno
2. Procedimentos - métodos executados por seus efeitos colaterais

O Ruby não tem uma maneira nativa de diferenciá-los - o que o deixa vulnerável a escrever um procedimento side_effect()e outro desenvolvedor que decide abusar do valor implícito de retorno do seu procedimento (basicamente tratando-o como uma função impura).

Para resolver isso, retire uma folha do livro de Scala e Haskell e faça com que seus procedimentos retornem explicitamente nil(aka Unitou ()em outros idiomas).

Se você seguir isso, o uso de returnsintaxe explícita ou não se tornará apenas uma questão de estilo pessoal.

Para distinguir ainda mais entre funções e procedimentos:

1. Copie a boa idéia de Jörg W Mittag de escrever blocos funcionais com chaves, e blocos procedurais com do/end
2. Ao invocar procedimentos, use (), enquanto que ao invocar funções, não

Observe que Jörg W Mittag realmente defendeu o contrário - evitando ()s para procedimentos -, mas isso não é aconselhável, porque você deseja que as invocações de métodos com efeito colateral sejam claramente distinguíveis das variáveis, principalmente quando a aridade é 0. Consulte o guia de estilo Scala sobre invocação de métodos para detalhes.

O guia de estilo declara que você não deve usar returnsua última declaração. Você ainda pode usá-lo se não for o último . Essa é uma das convenções que a comunidade segue estritamente, e você também deve fazer isso se planejar colaborar com alguém que usa Ruby.

Dito isto, o principal argumento para o uso de returns explícito é que é confuso para pessoas vindas de outras línguas.

• Em primeiro lugar, isso não é totalmente exclusivo para Ruby. Por exemplo, Perl também possui retornos implícitos.
• Em segundo lugar, a maioria das pessoas a quem isso se aplica é proveniente de idiomas algol. A maioria deles é "nível mais baixo" que o Ruby, portanto, você precisa escrever mais código para fazer alguma coisa.

Uma heurística comum para o comprimento do método (excluindo getters / setters) em java é uma tela . Nesse caso, você pode não estar vendo a definição do método e / ou já se esqueceu de onde estava retornando.

Por outro lado, no Ruby é melhor seguir métodos com menos de 10 linhas . Dado isso, alguém poderia se perguntar por que ele tem que escrever ~ 10% mais declarações, quando elas estão claramente implícitas.

Como Ruby não possui métodos nulos e tudo é muito mais conciso, você estará adicionando sobrecarga para nenhum dos benefícios se usar returns explícitos .

Eu concordo com Ben Hughes e discordo de Tim Holt, porque a pergunta menciona a maneira definitiva como o Python faz e pergunta se Ruby tem um padrão semelhante.

Faz.

Esse é um recurso tão conhecido da linguagem que qualquer pessoa que depure um problema no ruby ​​deve razoavelmente saber disso.

É uma questão de qual estilo você prefere na maior parte. Você precisa usar a palavra-chave return se desejar retornar de algum lugar no meio de um método.

Como Ben disse. O fato de 'o valor de retorno de um método ruby ​​ser o valor de retorno da última instrução no corpo da função' faz com que a palavra-chave return raramente seja usada na maioria dos métodos ruby.

def some_func_which_returns_a_list( x, y, z)
  return nil if failed_some_early_check


  # function code 

  @list     # returns the list
end