Dichiarazione delle variabili di ritorno nei metodi c # rispetto alla restituzione diretta del valore


17

In un dibattito sulle variabili di ritorno, alcuni membri del team preferiscono un metodo per restituire il risultato direttamente al chiamante, mentre altri preferiscono dichiarare una variabile di ritorno che viene quindi restituita al chiamante (vedere esempi di codice di seguito)

L'argomento di quest'ultimo è che consente a uno sviluppatore che sta eseguendo il debug del codice di trovare il valore di ritorno del metodo prima che ritorni al chiamante, facilitando così la comprensione del codice: ciò è particolarmente vero quando le chiamate al metodo sono concatenate.

Ci sono delle linee guida su quale sia il più efficiente e / o ci sono altri motivi per cui dovremmo adottare uno stile piuttosto che un altro?

Grazie

    private bool Is2(int a)
    {
        return a == 2;
    }

    private bool Is3(int a)
    {
        var result = a == 3;
        return result;
    }

11
Entrambi gli esempi verranno compilati con IL identico. L'unico motivo per cui si desidera il secondo esempio è per scopi di debug o se è necessario utilizzarlo resultprima di restituirlo.
ChrisF

1
Un altro motivo sarebbe perché è necessario fare qualcos'altro tra il calcolo del risultato e la sua restituzione.
Martedì

1
@ChrisF, in realtà non compilano lo stesso IL per me (ce ne sono altri stloc.0e ldloc.0nella seconda versione). Ma penso che ciò avvenga solo in modalità Debug. E comunque non è molto importante qui.
svick,

@svick - OK - Avrei dovuto aggiungere "in modalità di rilascio";)
ChrisF

1
Dal momento che puoi e talvolta dovresti (per brevità) scrivere qualcosa che assomigli: a = b = c;e a == b == c, eviterei di scrivere qualcosa che assomigli a = b == cse puoi. Quando ho visto per la prima volta una riga di codice simile, mi ci sono voluti alcuni secondi per capire cosa stesse succedendo. Quel codice si è distinto. Vorrei dare una a == 3pacca sulla parentesi , ma a StyleCop non piace - un buon motivo per usare la versione numero uno. Qualcos'altro: questo è essenzialmente un lambda, come a => (a == 3). Perché aggiungere una riga di codice a una funzione banale già gonfia?
Giobbe

Risposte:


7

Poiché utilizzo Resharper con Visual Studio, Ctrl-RV (o Ctrl-Alt-V, se si utilizzano le associazioni di tasti Resharper / IntelliJ) trasforma il primo esempio nel secondo esempio. Quindi, quando voglio eseguire il debug, posso farlo abbastanza facilmente. E se dimentico di rimetterlo, non mi sentirò male perché Ctrl-RI lo riporterà di nuovo per rendere più facile la lettura.

Seriamente, perdi tempo a discutere di cose più importanti. Ad esempio dove posizionare le parentesi graffe o gli spazi principali rispetto alle schede.


5
Preferisco che i miei dibattiti riguardino personaggi invisibili ...
ChaosPandion,

Ottimo consiglio, ragazzi! Ora possiamo ricodificare continuamente il codice degli altri molto più rapidamente di prima. Probabilmente risparmierai più tempo rispetto a discuterne! :)
pb01

@pdr che ctrl + RV funziona solo con resharper? o è una sorta di keybind personalizzato? per me non funziona.
Jane Doe,

@JaneDoe: Sono sbalordito nello scoprire che si tratta di un refactoring di Resharper e che VS non ha un equivalente. Risposta corretta Mi dispiace per quello.
pdr

@ChaosPandion U + 200B per la vittoria!
Jesse C. Slicer,

18

Personalmente trovo il primo esempio più facile da leggere. È ancora possibile eseguire il debug impostando un punto di interruzione nell'istruzione return e aggiungendolo a == 2alla finestra di controllo o utilizzando la visualizzazione rapida.

Ma questa è davvero una questione di preferenze personali. Entrambe le versioni sono OK.


8
+1 raddrizzamento più difficile da leggere il codice per rendere l'immissione punti di rottura più facile è fare le cose l'imho rotonda modo sbagliato
JK.

La finestra di controllo o la finestra intermedia non sono sempre soluzioni a questo problema, poiché a volte l'espressione richiede l'esecuzione del thread.
JustAnotherUserYouMayKnowOrNon

@JustAnotherUserYouMayKnowOrNot: Sì. C'è anche la possibilità di stampare un messaggio nella finestra di debug da un punto di interruzione. Fare clic con il tasto destro del mouse sul punto di interruzione e selezionare "When Hit ...".
Olivier Jacot-Descombes,

Anche l'espressione potrebbe avere effetti collaterali, eseguirla di nuovo potrebbe causare problemi. Meglio attenersi al risultato var.
JustAnotherUserYouMayKnowOrNon

9

Quando il codice è facilmente leggibile come il tuo esempio, non c'è nulla di sbagliato nel restituire il risultato di un'operazione logica come return a == 2. Tuttavia, se il valore restituito è un'istruzione più complessa o simile

return a > 2? doOptionA().getResult() > makeDecision("greaterThan2") : doOptionB().getResult() == makeDecision("lessThan2");

quindi ti consigliamo di utilizzare le variabili per memorizzare prima le parti e semplificare l'istruzione return, per motivi di leggibilità.


2

In un semplice esempio come quello, uno dei due è OK.

Per esempi più complicati, preferisco il secondo modo. Questo è solo perché è più leggibile e altri probabilmente dovranno mantenere il codice.


Solo se esiste un nome variabile migliore di result, che è esso stesso un identificatore completamente non descrittivo e inutile.
Alexander - Ripristina Monica il
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.