È buona norma nominare la variabile restituita "risultato"? [chiuso]

È buona norma chiamare la variabile restituita da un metodo con un nome variabile result?

Per esempio:

public Zorglub calculate() {
    Zorglub result = [...]
    [...]
    return result;
}

O dovrei nominarlo dal suo tipo?

public Zorglub calculate() {
    Zorglub zorglub = [...]
    [...]
    return zorglub;
}

Ho visto entrambi allo stato brado, se devo sceglierne uno, quali motivi potrebbero farmi preferire il primo o il secondo (o un nome migliore)?

Penso principalmente a Java.

Se questa è una variabile di metodo, dipende davvero dalla leggibilità.

Visto che hai già il nome del tipo sia nella dichiarazione della variabile che nel tipo di ritorno del metodo, potresti anche usare result- è descrittivo del ruolo della variabile.

La lettura incrociata è più semplice se la variabile è denominata result. Questo rende chiara la tua intenzione.

Se ho bisogno di una variabile di ritorno (che in realtà accade raramente), la chiamo retsempre e la definisco sempre proprio sotto la testa della funzione. La funzione ha già un nome, che dice tutto su ciò che restituisce.

Se ho myFunctionho potuto nominare variabile di ritorno è di myFunctionReturnValuedire esattamente la stessa cosa, solo avrei dovuto dirlo in modo esplicito ogni singola volta. Poiché le funzioni dovrebbero generalmente essere brevi, non è necessario tale esplicitazione. E anche se perdo la traccia, posso saltare alla dichiarazione e atterrerò proprio sotto la definizione della funzione.

Ma qualsiasi altro nome, che non implica implicitamente (come reto result) o esplicitamente (come myFunctionReturnValueo myFunctionResult), che questa è la funzione di ritorno delle variabili correnti è troppo generico.

Nel tuo secondo esempio zorglubè una scelta terribile. Tutto ciò che la dichiarazione mi dice davvero è che hai creato una variabile, il cui nome è uguale all'annotazione del tipo che si trova proprio accanto al nome. È utile quanto int someInto Zorglub z.

Nel tuo primo esempio, quando guardo il codice, vedo prima il nome della funzione, che mi dice, che questa funzione calcola a Zorglub. Mentre leggo la seconda riga vedo "ok, ecco lo zorglub, che verrà restituito, ma evidentemente non può essere restituito immediatamente ed è quindi memorizzato nella resultvariabile" (come nota a margine: se stai non hai intenzione di riassegnare il valore, quindi è meglio dichiarare la variabile final per comunicarlo), e poi penso "quindi vediamo ora cosa succede prima che venga restituito". A differenza del primo esempio, non ho bisogno di leggere oltre a quello per sapere che questa è la variabile, che verrà restituita e che voglio seguire nel corpo della funzione se voglio capirla.

Potresti voler leggere su Spartan Programming , che è piuttosto correlato alla tua domanda.

Nel tuo secondo esempio, stai combinando il tipo di risultato con quello che è .

Zorglub zorglub;

mi dice solo che è uno Zorglub, due volte. Tre volte se mi preoccupo di leggere il tipo restituito dal metodo. Tuttavia,

double variance;

ad esempio, mi dà un'idea di cosa significhi il valore restituito , in termini di semantica del programma. Può essere o non essere più chiaro della semplice chiamata result, a seconda delle dimensioni del metodo: questa è una richiesta di giudizio per ciascun metodo IMO.

Se si gioca con molti oggetti Zorglub nei vostri metodi, si "potrebbe" fare un errore e tornare quello sbagliato, e / o si potrebbe essere tentati di chiamare gli altri zorglub1, zorglub2, etc.

Se lo chiami result, non c'è alcuna possibilità che tu faccia un errore del genere. Inoltre, trovo che sia un buon nome; Ho anche visto returnedValueo returnedObjectpiù volte, è anche chiaro anche se un po 'lungo.

Personalmente non mi sento completamente a mio agio usando resultcome nome variabile. Abbastanza giusto, mi dice che il valore associato è il risultato di alcuni calcoli - tuttavia, suppongo che sia vero per circa (o oltre) il 90% delle variabili / campi utilizzati in un programma.

Inoltre, come notato da diverse altre risposte, può essere utilizzato per contrassegnare il valore da restituire da un metodo / funzione. Tuttavia, se mantengo i miei metodi brevi, concentrati sul fare solo una cosa e rimanere coerentemente su un singolo livello di astrazione, non avrò molte variabili locali e sarà banale vedere cosa restituirà un metodo.

Quindi preferisco mantenere i miei metodi brevi e puliti e nominare le mie variabili per esprimere il significato del valore che detengono, piuttosto che il suo ruolo locale all'interno del metodo allegato. Tuttavia, (ad esempio nel codice legacy) Zorglub resultpuò essere sicuramente più facile da capire rispetto a Zorglub zorglub.

Personalmente uso il nome resultper il valore da restituire dalla funzione / metodo. Rende esplicito che è il valore da restituire. La denominazione per tipo non sembra utile, perché potrebbero esserci più di una variabile dello stesso tipo.

Qual è la differenza? sono solo 2 parole diverse che faranno la stessa cosa, quindi il vero problema è quale ti sembra più chiaro?

Il "risultato" o "zorglub".

Preferirei usare ZorglubResultper iniziare per vedere che il risultato ritorna da Zorglub più facile da confrontare con altri risultati che potresti avere ed è un risultato come puoi vedere ..

dovrei nominarlo dal suo tipo?

No. Mai. Questo si chiama sistemi ungheresi ed è banalmente superato dall'idea di utilizzare un programma in grado di visualizzare il tipo di qualsiasi variabile ogni volta che ne hai bisogno.

Ogni volta che è necessario nominare qualcosa nel codice, è necessario fornire nomi descrittivi, significativi e leggibili. Il caso di una variabile di ritorno è un esempio particolarmente buono di dove le persone tendono a diventare compiacenti per la denominazione.

Se hai una funzione che è chiaramente denominata e hai bisogno di una sola riga di codice, puoi saltare completamente la denominazione. Rendere i tuoi metodi brevi e un unico scopo è sempre l'ideale a cui dovresti puntare. Tuttavia, a volte è necessario completare una funzione con più righe di codice. In questi casi è sempre consigliabile nominare la variabile in modo che corrisponda allo scopo della funzione.

Se lo scopo della funzione è quello di restituire il risultato di un calcolo o di un algoritmo di decisione, allora resultè un nome perfettamente adeguato per la variabile da utilizzare, ma cosa succede se la funzione restituisce un elemento da un elenco? Che cosa succede se la tua funzione ha qualche altro scopo che non ha nulla a che fare con la matematica o le liste? In questi casi, è meglio fornire alla variabile un nome significativo correlato al motivo per cui la funzione è stata creata. Certo, potresti semplicemente usare il risultato se lo desideri, perché è un nome che non è probabile che si scontri con nient'altro, tuttavia dal punto di vista della leggibilità ha più senso nominare la tua variabile in modo più significativo e nel contesto.

Mi piace combinarli, mostra di cosa si tratta e che è destinato a essere restituito.

quindi nel tuo esempio sarebbe risultatoZorglub

se ciò che è non importa davvero di quanto sarebbe solo il risultato (non resultString)

Non vedo molta differenza tra l'impostazione di un valore restituito ad un certo punto e quindi l'uso dei condizionali per saltare tutto il codice che potrebbe modificarlo, e returning subito, quindi vado per il ritorno diretto, quindi non c'è alcuna resultvariabile.

Se hai un valore intermedio che può essere cambiato o meno dal codice condizionale, allora non è un risultato (ancora), quindi sicuramente non dovrebbe essere chiamato così.

Quando stavo lavorando in C ++ e immagino che questo potrebbe valere per Java.

per esempio

int Width() const
{
    Requires(....);
    Requires(....);

    //calculation

    Ensures(...);
    Ensures(...);
    return Result;
}

Questo è progettato per contratto, poiché il blocco di sicurezza dovrebbe essere alla fine del metodo. Ma il ritorno deve essere l'ultimo. Avevamo la regola che restituire il risultato fosse l'unica cosa che potesse seguire il blocco di sicurezza.

In una funzione ricorsiva, è spesso efficace portare il risultato da un passo all'altro, per ottenere un'ottimizzazione della coda. Per segnalare all'utente che non è necessario fornire un parametro, può essere ragionevole nominare un parametro "risultato":

def removeOccurence [A] (slice: Seq[A], original: Seq[A]) = {
  @scala.annotation.tailrec
  def remove (leftOriginal: Seq[A], result: Seq[A]) : Seq[A] =
    trimStart (slice, leftOriginal) match {
      case (h :: tail) => remove (tail, h +: result)
      case (Nil)       => result.reverse
    }
    remove (original, Nil)
}

Ma più spesso uso "carry" e "sofar", che ho visto in natura e che portano l'idea anche un po 'meglio, nella maggior parte dei casi.

Un secondo motivo è ovviamente se l'argomento suggerisce la parola "risultato", ad esempio se si esegue una valutazione aritmetica. È possibile analizzare la formula, sostituire le variabili con valori e calcolare un risultato alla fine.

Un terzo motivo è già stato dichiarato, ma ho una piccola deviazione: scrivi un metodo che esegue un lavoro, diciamo che valuta una forma di '' max ''.

def max = {
  val result = somethingElseToDo
  if (foo) result else default 
}

Invece di chiamare il risultato '' risultato '', potremmo chiamarlo '' max '', ma in alcune lingue è possibile omettere la parentesi quando si chiama un metodo, quindi max sarebbe una chiamata ricorsiva al metodo stesso.

In generale, preferirei un nome che indichi quale sia il risultato. Ma se quel nome è già preso, forse da più di una variabile, attributo o metodo, perché esiste un campo GUI, una rappresentazione di stringa, un valore numerico e uno per il database, l'uso di un altro aumenta la probabilità di confusione. In metodi brevi da 3 a 7 righe, il '' risultato '' non dovrebbe essere un problema per un nome.

In Object Pascal questa non è una scelta. Devi assegnare un valore alla Resultvariabile da qualche parte nel codice della funzione.

Esempio:

function AddIntegers( A,B: Integer): Integer;
begin
  Result := A + B; 
end; 

Quindi per me è abbastanza naturale avere una variabile "Risultato" (o "Retorno", come lo scrivo in portoghese per evitare conflitti di nomi con le parole riservate della lingua) per ricevere un valore di ritorno.

Naturalmente, se è un'espressione molto semplice in un linguaggio derivato dalla C, non mi prenderò la briga di dichiarare una variabile risultante, restituendo direttamente l'espressione.

non è solo quello che chiami il risultato (io sono particolare di 'r'), ma anche come viene usato. per esempio, se hai una variabile return, allora ogni istruzione return dovrebbe restituirla. non avere "return r;" alla fine, ma cospargere cose come 'return m * x + b; "in tutto il metodo / funzione. usa" r = m * x + b; return r; "invece.

il risultato va bene. Sono in grado di capire il codice a prima vista, quindi il nome della variabile ha servito allo scopo.