È una cattiva pratica usare il ritorno all'interno di un metodo void?

Immagina il seguente codice:

void DoThis()
{
    if (!isValid) return;

    DoThat();
}

void DoThat() {
    Console.WriteLine("DoThat()");
}

Va bene usare un ritorno all'interno di un metodo void? Ha qualche penalità sulle prestazioni? Oppure sarebbe meglio scrivere un codice come questo:

void DoThis()
{
    if (isValid)
    {
        DoThat();
    }
}

Un ritorno in un metodo void non è male, è pratica comune invertire le ifistruzioni per ridurre l'annidamento .

E avere meno annidamenti sui metodi migliora la leggibilità e la manutenibilità del codice.

In realtà, se hai un metodo void senza alcuna istruzione return, il compilatore genererà sempre un'istruzione ret alla fine di esso.

C'è un altro ottimo motivo per usare guards (al contrario del codice annidato): se un altro programmatore aggiunge codice alla tua funzione, sta lavorando in un ambiente più sicuro.

Prendere in considerazione:

void MyFunc(object obj)
{
    if (obj != null)
    {
        obj.DoSomething();
    }
}

contro:

void MyFunc(object obj)
{
    if (obj == null)
        return;

    obj.DoSomething();
}

Ora, immagina che un altro programmatore aggiunga la riga: obj.DoSomethingElse ();

void MyFunc(object obj)
{
    if (obj != null)
    {
        obj.DoSomething();
    }

    obj.DoSomethingElse();
}

void MyFunc(object obj)
{
    if (obj == null)
        return;

    obj.DoSomething();
    obj.DoSomethingElse();
}

Ovviamente questo è un caso semplicistico, ma il programmatore ha aggiunto un arresto anomalo al programma nella prima istanza (codice annidato). Nel secondo esempio (uscita anticipata con guardie), una volta superata la guardia, il tuo codice è al sicuro dall'uso involontario di un riferimento nullo.

Certo, un grande programmatore non commette errori come questo (spesso). Ma prevenire è meglio che curare: possiamo scrivere il codice in modo da eliminare completamente questa potenziale fonte di errori. La nidificazione aggiunge complessità, quindi le best practice consigliano di refactoring del codice per ridurre la nidificazione.

Cattiva pratica ??? Non c'è modo. In effetti, è sempre meglio gestire le convalide ritornando dal metodo al più presto se le convalide falliscono. Altrimenti risulterebbe in un'enorme quantità di se e altri nidificati. Terminare anticipatamente migliora la leggibilità del codice.

Controlla anche le risposte a una domanda simile: devo usare l'istruzione return / continue invece di if-else?

Non è una cattiva pratica (per tutti i motivi già indicati). Tuttavia, maggiori sono i rendimenti che si hanno in un metodo, più è probabile che venga suddiviso in metodi logici più piccoli.

Il primo esempio sta usando un'istruzione guard. Da Wikipedia :

Nella programmazione di computer, una guardia è un'espressione booleana che deve restituire true se l'esecuzione del programma deve continuare nel ramo in questione.

Penso che avere un gruppo di guardie all'inizio di un metodo sia un modo perfettamente comprensibile per programmare. Fondamentalmente sta dicendo "non eseguire questo metodo se qualcuno di questi è vero".

Quindi in generale vorrebbe questo:

void DoThis()
{
  if (guard1) return;
  if (guard2) return;
  ...
  if (guardN) return;

  DoThat();
}

Penso che sia molto più leggibile quindi:

void DoThis()
{
  if (guard1 && guard2 && guard3)
  {
    DoThat();
  }
}

Non ci sono penalità sulle prestazioni, tuttavia la seconda parte di codice è più leggibile e quindi più facile da mantenere.

In questo caso, il tuo secondo esempio è un codice migliore, ma questo non ha nulla a che fare con il ritorno da una funzione void, è semplicemente perché il secondo codice è più diretto. Ma il ritorno da una funzione void va benissimo.

Va perfettamente bene e nessuna "penalizzazione delle prestazioni", ma non scrivere mai un'istruzione "if" senza parentesi.

Sempre

if( foo ){
    return;
}

È molto più leggibile; e non presumerai mai accidentalmente che alcune parti del codice siano all'interno di tale istruzione quando non lo sono.

Non sarò d'accordo con tutti voi giovani whippersnapper su questo.

Usare il ritorno nel mezzo di un metodo, vuoto o meno, è una pessima pratica, per ragioni che sono state articolate abbastanza chiaramente, quasi quarant'anni fa, dal compianto Edsger W. Dijkstra, a partire dalla nota "Dichiarazione GOTO Considered Harmful ", e proseguendo in" Programmazione strutturata ", di Dahl, Dijkstra e Hoare.

La regola di base è che ogni struttura di controllo e ogni modulo dovrebbero avere esattamente un'entrata e un'uscita. Un ritorno esplicito nel mezzo del modulo infrange questa regola e rende molto più difficile ragionare sullo stato del programma, il che a sua volta rende molto più difficile dire se il programma è corretto o meno (cheèuna proprietà molto più forte di "se sembra funzionare o no").

"Dichiarazione GOTO considerata dannosa" e "Programmazione strutturata" hanno dato il via alla rivoluzione "Programmazione strutturata" degli anni '70. Questi due pezzi sono i motivi per cui abbiamo if-then-else, while-do e altri costrutti di controllo espliciti oggi, e perché le dichiarazioni GOTO nei linguaggi di alto livello sono nell'elenco delle specie in pericolo. (La mia opinione personale è che devono essere nell'elenco delle specie estinte.)

Vale la pena notare che il Message Flow Modulator, il primo pezzo di software militare che MAI ha superato i test di accettazione al primo tentativo, senza deviazioni, rinunce o parole "sì, ma", è stato scritto in una lingua che non aveva nemmeno un'istruzione GOTO.

Vale anche la pena ricordare che Nicklaus Wirth ha cambiato la semantica dell'istruzione RETURN in Oberon-07, l'ultima versione del linguaggio di programmazione Oberon, rendendolo un pezzo finale della dichiarazione di una procedura tipizzata (cioè una funzione), piuttosto che una istruzione eseguibile nel corpo della funzione. La sua spiegazione del cambiamento diceva che lo aveva fatto proprio perché il modulo precedente ERA una violazione del principio di una sola uscita della programmazione strutturata.

Durante l'utilizzo delle protezioni, assicurati di seguire alcune linee guida per non confondere i lettori.

• la funzione fa una cosa
• le guardie vengono introdotte solo come prima logica nella funzione
• la parte non testata contiene l' intento principale della funzione

Esempio

// guards point you to the core intent
void Remove(RayCastResult rayHit){

  if(rayHit== RayCastResult.Empty)
    return
    ;
  rayHit.Collider.Parent.Remove();
}

// no guards needed: function split into multiple cases
int WonOrLostMoney(int flaw)=>
  flaw==0 ? 100 :
  flaw<10 ? 30 :
  flaw<20 ? 0 :
  -20
;

Genera un'eccezione invece di restituire nulla quando l'oggetto è nullo ecc.

Il tuo metodo si aspetta che l'oggetto non sia nullo e non è così, quindi dovresti lanciare un'eccezione e lasciare che il chiamante lo gestisca.

Ma il ritorno anticipato non è una cattiva pratica altrimenti.