VB.NET Funzione Return

Per restituire un valore da una funzione VB.NET, è ansible assegnare un valore al “Nome funzioni” o utilizzare “valore restituito”.

A volte vedo questi inter-misti nella stessa funzione. Personalmente, preferisco il ritorno.

La mia domanda è, qual è la differenza interna, se esiste, tra i due?

Probabilmente non c’è differenza. IIRC, il compilatore generato IL converte entrambi in istruzioni Return a meno che non ci sia un uso aggiuntivo di una variabile _returnValue.

A mio parere, la leggibilità del compito FunctionName è scarsa e un esempio di ctriggers abitudine VB6. Preferisco anche il metodo variabile _returnValue (NOT RETVAL).

La differenza è che FANNO COSE DIVERSE!

‘Valore di ritorno’ fa 2 cose:
1. Imposta il valore di ritorno della funzione in quel punto 2. Esce immediatamente dalla funzione

Nessun altro codice nella funzione viene eseguito!

‘Functionname = value’ fa 1 cosa: 1. Imposta il valore di ritorno della funzione in quel punto

L’altro codice nella funzione continua ad essere eseguito Ciò abilita la logica aggiuntiva per perfezionare o sovrascrivere il valore di ritorno della funzione

Enorme differenza gente Ricorda che non si tratta solo di stato, ma anche di stream.

Diamo un’occhiata … Stranamente “functionName =” genera meno IL?

Codice:

Public Function Test() As String Test = "Test" End Function Public Function Test2() As String Return "Test" End Function 

I L:

 .method public static string Test() cil managed { .maxstack 1 .locals init ( [0] string Test) L_0000: nop L_0001: ldstr "Test" L_0006: stloc.0 L_0007: ldloc.0 L_0008: ret } .method public static string Test2() cil managed { .maxstack 1 .locals init ( [0] string Test2) L_0000: nop L_0001: ldstr "Test" L_0006: stloc.0 L_0007: br.s L_0009 L_0009: ldloc.0 L_000a: ret } 

La seguente operazione viene fornita solo agli sviluppatori di Visual Basic 6.0 per eseguire facilmente il porting del codice su:

 Public Function MyFunction() As String MyFunction = "Hello" End Function 

Non raccomanderei assolutamente di continuare a farlo se il progetto include qualcuno che non ha lavorato con Visual Basic 6.0, in quanto questa syntax potrebbe confondere.

99 volte su 100 userò il “valore di ritorno”.

Ogni tanto avrò una funzione in cui l’altro tipo non solo mi consente di salvare una dichiarazione di variabile, ma di farlo in un modo che chiarisca in modo significativo la funzione. Di solito questo accade quando vorrei nominare comunque il valore di ritorno uguale alla funzione, e spesso queste sono funzioni ricorsive; qualcosa su quel costrutto lo presta alla variabile di ritorno implicita. Tuttavia, questo scenario è estremamente raro . Non so se ho alcune funzioni che utilizzano variabili di ritorno implicite nel mio progetto corrente.

Avendo letto che la syntax del valore di ritorno era l’unico modo True .NET di fare le cose, ho pensato “OK, lo faremo in quel modo”. Poi ho scritto una funzione che conoscevo, mano sul cuore KNEW, restituiva un valore da un’istruzione Return o alternativamente un’eccezione in tutte le circostanze, e ricevevo comunque un compilatore che avverte che la funzione “non restituisce un valore su tutti i percorsi” .

Per fortuna mi sono imbattuto nella domanda Stack Overflow. Come posso fare in modo che questa funzione non generi un avviso “non restituisce un valore su tutti i percorsi”? che spiegava perché; l’aggiunta di un’assegnazione di valori di default al nome della procedura all’inizio della funzione ha impedito anche l’avviso nel mio caso.

Di conseguenza, anche se continuerò ad usare la syntax Return Value semplicemente per coerenza di syntax, assegnerò anche un valore predefinito al nome della funzione solo per evitare la possibilità di ingombrare il processo di compilazione con avvisi fasulli.