È buona pratica denominare la variabile restituita "risultato"? [chiuso]

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 . Ciò rende chiara la tua intenzione.

Se ho bisogno di una variabile di ritorno (che in realtà accade raramente), la chiamo sempre ret 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 myFunction I potrebbe denominare la sua variabile di ritorno myFunctionReturnValue per dire esattamente la stessa cosa, solo dovrei dirlo esplicitamente ogni volta. Poiché le funzioni dovrebbero generalmente essere brevi, non c'è bisogno di un tale esplicito. E anche se perdo traccia, posso saltare alla dichiarazione e atterrerò proprio sotto la definizione della funzione.

Ma qualsiasi altro nome, che non implicitamente (come ret o result ) o esplicitamente (come myFunctionReturnValue o myFunctionResult ) dichiari, che questa è la variabile di ritorno delle funzioni correnti è troppo generica.

Nel tuo secondo esempio zorglub è una scelta terribile. Tutta la dichiarazione in realtà mi dice che hai creato una variabile, il cui nome è uguale al tipo di annotazione trovata proprio accanto al nome. È utile tanto quanto int someInt o Zorglub z .

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

Potresti leggere su Programmazione spartana , che è piuttosto correlato a la tua domanda.

Nel tuo secondo esempio, confondi il tipo del risultato con che cos'è .

Zorglub zorglub;

mi dice che è uno Zorglub, due volte. Tre volte se mi prendo la briga di leggere il metodo return type. Tuttavia,

double variance;

per esempio, mi dà un'idea di quale sia il valore di ritorno che significa , in termini di semantica del programma. Può essere o non essere più chiaro del semplice chiamarlo result , a seconda delle dimensioni del metodo - questo è un giudizio per ogni metodo IMO.

Se giochi con molti oggetti Zorglub nei tuoi metodi, "potresti" commettere un errore e restituire quello sbagliato, o / e potresti essere tentato di nominare gli altri zorglub1 , zorglub2 , ecc.

Se lo chiami result , non c'è possibilità che tu commetta un errore del genere. Inoltre, trovo che sia un buon nome; Ho anche visto returnedValue o returnedObject più volte, è anche chiaro anche se un po 'lungo.

Personalmente non sono del tutto a mio agio usando result come nome di variabile. Abbastanza corretto, mi dice che il valore associato è il risultato di qualche computazione - tuttavia, suppongo che sia vero circa il (o oltre) 90% delle variabili / campi usati in un programma.

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

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 di inclusione. Tuttavia, (ad es. Nel codice precedente) Zorglub result può essere più semplice da capire rispetto a Zorglub zorglub .

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

Qual è la differenza? ci sono solo 2 parole diverse che faranno la stessa cosa, quindi il vero problema è quale suona più chiaro per te?

Il "risultato" o "zorglub".

Preferirei usare ZorglubResult per uno starter per vedere che restituisce risultati da Zorglub più facili da confrontare con altri risultati che potresti avere ed è un risultato come puoi vedere ..

should I name it by its type?

No. Mai. Questo sistema si chiama Systems Hungarian 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 devi nominare qualsiasi nel codice, devi fornire nomi che siano descrittivi, significativi e leggibili. Il caso di una variabile di ritorno è un esempio particolarmente chiaro di dove le persone tendono a diventare compiacenti sulla denominazione.

Se hai una funzione che ha un nome chiaro e hai bisogno solo di una singola riga di codice, puoi saltare completamente la denominazione. Rendere i tuoi metodi brevi e unici è sempre l'ideale che dovresti mirare. Tuttavia, a volte è necessario completare una funzione con più righe di codice. In quei casi è sempre consigliabile denominare la variabile in modo che corrisponda allo scopo della propria funzione.

Se lo scopo della funzione è restituire il risultato di un calcolo o un algoritmo decisionale, quindi result è un nome perfettamente adeguato per la variabile da utilizzare, ma cosa succede se la funzione restituisce un elemento da un elenco? Cosa succede se la tua funzione sta servendo qualche altro scopo che non ha nulla a che fare con la matematica o le liste? In questi casi, è meglio fornire la variabile con un nome significativo che si riferisce al motivo per cui la funzione è stata creata. Certo, potresti semplicemente usare il risultato se lo volessi, perché è un nome che non rischia di scontrarsi con qualcos'altro, tuttavia dal punto di vista della leggibilità ha più senso denominare la tua variabile in modo più significativo e contestualizzato.

Mi piace abbinarli, mostrare di cosa si tratta e che si intende restituire.

quindi nel tuo esempio sarebbe resultZorglub

se quello che è non importa molto di quanto sarebbe solo risultato (non resultString)

Non vedo molta differenza tra l'impostazione di un valore di ritorno ad un certo punto e l'uso di condizionali per saltare tutto il codice che potrebbe modificarlo, e return ing subito, quindi vado per il ritorno diretto, quindi non esiste una variabile result .

Se hai un valore intermedio che può o non può essere modificato dal codice condizionale, allora non è un risultato (ancora), quindi certamente non dovrebbe essere nominato così.

Quando lavoravo in C ++ e immagino che questo possa essere applicato in Java.

per es.

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

    //calculation

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

Questo è design per contratto, poiché il blocco di garanzia dovrebbe essere alla fine del metodo. Ma il ritorno deve essere l'ultimo. Avevamo la regola che restituire Result era l'unica cosa che poteva seguire il blocco assicura.

In una funzione ricorsiva, è spesso efficace portare il risultato da un passaggio all'altro, per creare un'ottimizzazione della coda. Per segnalare all'utente, che non ha bisogno di 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 il tuo argomento suggerisce la parola "risultato", ad esempio se fai una valutazione aritmetica. È possibile analizzare la formula, sostituire le variabili con valori e calcolare un risultato alla fine.

Una terza ragione è già stata dichiarata, ma ho una piccola deviazione: scrivi un metodo che svolge un certo 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 le 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à stato preso, forse da più di una variabile, attributo o metodo, perché c'è un campo della GUI, una rappresentazione di stringa, una numerica e una per il database, usando un'altra aumenta la probabilità di confusione. In breve i metodi da 3 a 7 linee, '' risultato '' non dovrebbe essere un problema per un nome.

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

Esempio:

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

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

Però, se è un'espressione molto semplice in un linguaggio derivato da C, non mi preoccuperò di dichiarare una variabile risultato - restituendo l'espressione direttamente.

non è solo il nome del risultato (io sono particolare di "r"), ma anche il modo in cui viene utilizzato. per esempio, se hai una variabile di ritorno, allora ogni dichiarazione di ritorno dovrebbe restituirla. non avere 'return r;' alla fine, ma cospargere cose come 'return m * x + b; "in tutto il metodo / funzione, usare" 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 è servito allo scopo.