È un buon stile tornare esplicitamente in Ruby?

Proveniente da uno sfondo Python, dove c'è sempre un "modo giusto di farlo" (un modo "Pythonic") quando si tratta di stile, mi chiedo se lo stesso esiste per Ruby. Ho usato le mie linee guida di stile, ma sto pensando di rilasciare il mio codice sorgente e mi piacerebbe che aderisse a qualsiasi regola non scritta che potrebbe esistere.

È "The Ruby Way" a scrivere esplicitamente i returnmetodi? L'ho visto fatto con e senza, ma c'è un modo giusto per farlo? C'è forse il momento giusto per farlo? Per esempio:

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

Vecchia (e "risposta") domanda, ma aggiungerò i miei due centesimi come risposta.

TL; DR - Non è necessario, ma in alcuni casi può rendere il codice molto più chiaro.

Anche se non usare un ritorno esplicito può essere "la via di Ruby", è fonte di confusione per i programmatori che lavorano con codice non familiare o non hanno familiarità con questa funzionalità di Ruby.

È un esempio un po 'inventato, ma immagina di avere una piccola funzione come questa, che aggiunge uno al numero passato e lo assegna a una variabile di istanza.

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

Doveva essere una funzione che restituiva un valore o no? È davvero difficile dire cosa intendesse lo sviluppatore, poiché entrambi assegna la variabile di istanza e restituisce anche il valore assegnato.

Supponiamo molto più tardi, un altro programmatore (forse non così familiare con il modo in cui Ruby ritorna sulla base dell'ultima riga di codice eseguita) arriva e vuole inserire alcune istruzioni di stampa per la registrazione, e la funzione diventa questa ...

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

Ora la funzione è interrotta se qualcosa prevede un valore restituito . Se nulla prevede un valore restituito, va bene. Chiaramente se da qualche parte più in basso nella catena del codice, qualcosa che chiama questo si aspetta un valore restituito, fallirà perché non sta recuperando ciò che si aspetta.

La vera domanda ora è questa: qualcosa si aspettava davvero un valore restituito? Questo ha rotto qualcosa o no? Romperà qualcosa in futuro? Chissà! Solo una revisione completa del codice di tutte le chiamate ti farà sapere.

Quindi, almeno per me, l'approccio delle migliori pratiche è quello di essere molto esplicito che stai restituendo qualcosa se è importante, o di non restituire nulla quando non lo fa.

Quindi, nel caso della nostra piccola funzione demo, supponendo che volessimo restituire un valore, sarebbe scritto in questo modo ...

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

E sarebbe molto chiaro a qualsiasi programmatore che restituisce un valore, e molto più difficile per loro romperlo senza rendersene conto.

In alternativa, si potrebbe scrivere in questo modo ed escludere la dichiarazione di ritorno ...

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

Ma perché preoccuparsi di lasciare fuori la parola return? Perché non metterlo solo lì e chiarire al 100% cosa sta succedendo? Non avrà letteralmente alcun impatto sulla capacità di esecuzione del codice.

No. Un buon stile Ruby userebbe generalmente solo un ritorno esplicito per un ritorno anticipato . Ruby è grande sul minimalismo del codice / magia implicita.

Detto questo, se un ritorno esplicito renderebbe le cose più chiare o più facili da leggere, non danneggerebbe nulla.

Personalmente uso la returnparola chiave per distinguere tra quelli che chiamo metodi funzionali , ovvero metodi che vengono eseguiti principalmente per il loro valore di ritorno, e metodi procedurali che vengono eseguiti principalmente per i loro effetti collaterali. Pertanto, i metodi in cui il valore restituito è importante, ottengono una returnparola chiave aggiuntiva per attirare l'attenzione sul valore restituito.

Uso la stessa distinzione quando chiamo metodi: i metodi funzionali ottengono le parentesi, i metodi procedurali no.

E, ultimo ma non meno importante, uso anche questa distinzione con i blocchi: i blocchi funzionali ottengono parentesi graffe, i blocchi procedurali (cioè i blocchi che "fanno" qualcosa) ottengono do/ end.

Tuttavia, cerco di non essere religioso al riguardo: con blocchi, parentesi graffe e do/ endhanno una precedenza diversa, e piuttosto che aggiungere parentesi esplicite per chiarire un'espressione, passo semplicemente all'altro stile. Lo stesso vale per il metodo di chiamata: se l'aggiunta di parentesi all'elenco dei parametri rende il codice più leggibile, lo faccio, anche se il metodo in questione è di natura procedurale.

In realtà l'importante è distinguere tra:

1. Funzioni: metodi eseguiti per il loro valore di ritorno
2. Procedure: metodi eseguiti per i loro effetti collaterali

Ruby non ha un modo nativo di distinguerli, il che ti rende vulnerabile alla stesura di una procedura side_effect()e un altro sviluppatore che decide di abusare del valore di ritorno implicito della tua procedura (trattandola sostanzialmente come una funzione impura).

Per risolvere questo problema, prendi un foglio dal libro di Scala e Haskell e fai in modo che le tue procedure ritornino esplicitamente nil(aka Unito ()in altre lingue).

Se lo segui, l'uso della returnsintassi esplicita o non diventa solo una questione di stile personale.

Per distinguere ulteriormente tra funzioni e procedure:

1. Copia la simpatica idea di Jörg W Mittag di scrivere blocchi funzionali con parentesi graffe e blocchi procedurali con do/end
2. Quando invochi le procedure, usa (), mentre quando invochi funzioni, non farlo

Nota che Jörg W Mittag ha effettivamente sostenuto il contrario - evitando ()s per le procedure - ma questo non è consigliabile perché vuoi che le invocazioni dei metodi con effetti collaterali siano chiaramente distinguibili dalle variabili, in particolare quando l'arity è 0. Vedi la guida dello stile Scala sull'invocazione del metodo per dettagli.

La guida di stile afferma che non dovresti usare returnl'ultima dichiarazione. Puoi ancora usarlo se non è l'ultimo . Questa è una delle convenzioni che la comunità segue rigorosamente, e così dovresti se hai intenzione di collaborare con chiunque usi Ruby.

Detto questo, l'argomento principale per l'uso di espliciti returnè che è fonte di confusione per le persone che provengono da altre lingue.

• Innanzitutto, questo non è del tutto esclusivo per Ruby. Ad esempio, anche Perl ha rendimenti impliciti.
• In secondo luogo, la maggior parte delle persone a cui questo si applica proviene dalle lingue algolesi. Molti di questi sono molto più "bassi" di Ruby, quindi devi scrivere più codice per fare qualcosa.

Un euristico comune per la lunghezza del metodo (esclusi getter / setter) in Java è una schermata . In tal caso, potresti non vedere la definizione del metodo e / o aver già dimenticato da dove stavi tornando.

D'altra parte, in Ruby è meglio attenersi a metodi lunghi meno di 10 righe . Detto questo, ci si potrebbe chiedere perché debba scrivere il 10% in più di dichiarazioni, quando sono chiaramente implicite.

Dal momento che Ruby non ha metodi nulli e tutto è molto più conciso, stai solo aggiungendo un sovraccarico per nessuno dei vantaggi se vai con esplicite returns.

Sono d'accordo con Ben Hughes e non sono d'accordo con Tim Holt, perché la domanda menziona il modo in cui Python lo fa e chiede se Ruby ha uno standard simile.

Lo fa.

Questa è una caratteristica così ben nota del linguaggio che chiunque dovrebbe aspettarsi di eseguire il debug di un problema in Ruby dovrebbe ragionevolmente aspettarselo.

È una questione di quale stile preferisci per la maggior parte. È necessario utilizzare la parola chiave return se si desidera tornare da qualche parte nel mezzo di un metodo.

Come ha detto Ben. Il fatto che "il valore restituito di un metodo ruby ​​è il valore restituito dell'ultima istruzione nel corpo della funzione" fa sì che la parola chiave return sia utilizzata raramente nella maggior parte dei metodi 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