È necessario aggiungere il caso predefinito durante l'utilizzo dei casi switch?

Durante una recente revisione del codice mi è stato chiesto di inserire defaultcasi in tutti i file ovunque switchvenga utilizzato il blocco, anche se non c'è nulla da fare default. Ciò significa che devo mettere il defaultcaso e non scrivere nulla al suo interno.

È questa la cosa giusta da fare? Quale scopo servirebbe?

Sembra che ci siano tre casi in cui una defaultdichiarazione non è necessaria:

1. non rimangono altri casi, perché esiste un set limitato di valori che immettono il file switch case. Ma questo potrebbe cambiare con il tempo (intenzionalmente o accidentalmente), e sarebbe bene avere un default casecambiamento di qualsiasi cosa _ potresti registrare o avvisare l'utente di un valore errato.

2. sai come e dove switch caseverrà utilizzato e quali valori lo inseriranno. Ancora una volta, questo potrebbe cambiare e potrebbe essere necessaria un'elaborazione aggiuntiva.

3. altri casi non necessitano di particolari elaborazioni. In questo caso, penso che ti venga chiesto di aggiungere un default case, perché è uno stile di codifica accettato e rende il tuo codice più leggibile.

I primi due casi si basano su ipotesi. Quindi (supponendo che tu lavori in un team non così piccolo dato che hai regolari revisioni del codice), non puoi permetterti di fare quei presupposti. Non sai chi lavorerà con il tuo codice o effettuerà chiamate a funzioni / invocando metodi nel tuo codice. Allo stesso modo, potresti dover lavorare con il codice di qualcun altro. Avere lo stesso stile di codifica renderà più semplice la gestione del codice di qualcuno (incluso il tuo).

È questo il modo giusto di fare? Quale scopo servirebbe?

Non è raro che gli standard di codifica aziendale richiedano un caso predefinito per tutte le switchdichiarazioni. Uno dei motivi è che rende facile per i lettori trovare la fine del switch. Un'altra ragione, probabilmente migliore, è che ti fa riflettere per un secondo su cosa dovrebbe fare il tuo codice quando la condizione non corrisponde alle tue aspettative. Indipendentemente dal motivo del requisito, se si tratta di uno standard aziendale, è necessario seguirlo a meno che non vi sia un motivo ermetico per non farlo.

Se ritieni che switchincluda i casi per ogni possibile condizione, una buona cosa da fare è inserire assertun'istruzione nel caso predefinito. In questo modo, quando qualcuno modifica il codice e aggiunge inavvertitamente una condizione che la tua switchnon copre, colpirà asserte realizzerà che deve affrontare quella parte del codice.

Se il tuo switchcopre solo alcune delle possibili condizioni, ma nulla di speciale deve essere fatto per le altre, puoi lasciare vuoto il caso predefinito. È una buona idea aggiungere un commento in quel caso per indicare che il caso predefinito è intenzionalmente vuoto perché le condizioni che lo colpiscono non richiedono alcun lavoro da eseguire.

Se si "attiva" il tipo di enumerazione puro, è pericoloso avere un fallback predefinito. Quando successivamente si aggiungono valori al tipo di enumerazione, il compilatore evidenzia le opzioni con nuovi valori non coperti. Se hai una clausola predefinita lì, il compilatore rimarrà silenzioso e potresti perderlo.

Per molti aspetti, questa domanda è la stessa della domanda frequente Ho bisogno di una elseclausola alla fine di una if/ else ifscala che copre ogni opzione .

La risposta è, sintatticamente parlando, no, non è così. Ma c'è un ...

Una defaultclausola può essere presente per (almeno) due motivi:

1. Come gestore di errori - certo, non dovrei mai arrivare qui! è un'affermazione che può essere fatta, ma se fosse così? La corruzione dei dati, o peggio ancora, nessuna convalida dei dati sono percorsi per il fallimento del programma se non correttamente intrappolati. In questo caso, non dovrebbe essere una clausola vuota!
2. Copertura di progettazione / codice - anche nella forma più semplice di un diagramma di flusso, ci sono due percorsi da un'istruzione if e sempre otherwiseda un caso. Non vi è alcun motivo per non includerli nel codice sorgente.

La mia filosofia è sempre abbastanza semplice: valutare lo scenario peggiore delle due opzioni e scegliere il più sicuro. Nel caso di una clausola vuota elseo default, le opzioni peggiori sono:

• Includili: altre tre o quattro righe di codice "ridondante".
• Non includerli: i dati non autorizzati o una condizione imprevista non vengono intrappolati, causando potenzialmente un errore del programma.

Overdramatic? Forse ... ma poi il mio software ha il potenziale di uccidere le persone se va storto. Preferirei non correre questo rischio.

A parte questo, le linee guida MISRA-C {vedi profilo per affiliazione} raccomandano una defaultclausola per ogniswitch

Java non ti obbliga ad avere un'istruzione "predefinita", ma è buona norma averne sempre una, anche se il codice potrebbe non essere mai raggiunto (in questo momento). Ecco alcuni motivi:

Avendo una clausola di default irraggiungibile, mostri al lettore del tuo codice che hai considerato i valori e sai cosa stai facendo. Consenti anche modifiche future, ad esempio: viene aggiunto un nuovo valore enum, l'opzione non dovrebbe ignorare silenziosamente il nuovo valore; puoi invece lanciare un'eccezione o fare qualcos'altro.

Per ottenere un valore imprevisto (nel caso in cui non si stia attivando un enum) che viene passato, potrebbe essere maggiore o minore di quello previsto, ad esempio.

Per gestire le azioni "predefinite" - dove gli switch sono per comportamenti speciali. Ad esempio, una variabile potrebbe essere dichiarata all'esterno dell'interruttore ma non inizializzata e ogni caso la inizializza in qualcosa di diverso. L'impostazione predefinita in questo caso potrebbe inizializzarlo su un valore predefinito in modo che il codice immediatamente dopo lo switch non si verifichi / generi un'eccezione.

Anche se decidi di non inserire nulla nel valore predefinito (nessuna eccezione, registrazione, ecc.), Anche un commento per dire che hai considerato che il fatto predefinito non si verificherà mai può aiutare la leggibilità del tuo codice; ma ciò dipende dalle preferenze personali.

Vorrei anche aggiungere che dipende dalla filosofia della lingua che stai usando. Ad esempio, in Erlang, dove si tratta di un approccio comune per "lasciarlo andare in crash", non si definirebbe un caso predefinito ma si lascerebbe che la propria casedichiarazione generasse un errore se si verifica una situazione non soddisfatta.

Dovresti sempre avere un valore predefinito a meno che tu non abbia coperto in modo dimostrabile e permanente tutti i casi. Non costa nulla ed è un'assicurazione contro il fallimento nel mantenere la tua dichiarazione di cambio in un programma in evoluzione.

Se sei davvero sicuro di non preoccuparti di nessun altro caso, il default: break; // non importa ma il default predefinito dovrebbe essere qualcosa come default: generate new Error ("valore inatteso");

Allo stesso modo, non dovresti mai "scorrere" un costrutto di caso non banale senza aggiungere un commento all'effetto che intendi eliminare. Java ha sbagliato questo in fase di progettazione.

Ritenere

enum Gender
{
       MALE ,
       FEMALE ;
}

e

void run ( Gender g )
{
      switch ( g )
      {
           case MALE :
                 // code related to males
                 break ;
           default :
                 assert Gender . FEMALE . equals ( g ) ;
                 // code related to females
                 break ;
      }
}

Direi che questo è superiore all'avere un caso MASCHIO, un caso FEMMINA e un caso predefinito che genera un'eccezione.

Durante la fase di test, il computer verificherà se g è FEMMINA. Durante la produzione, il controllo verrà omesso. (Sì, una microottimizzazione!)

Ancora più importante, manterrai il tuo obiettivo di copertura del codice al 100%. Se hai scritto un caso predefinito che genera un'eccezione, come lo testeresti mai?