Domanda

In una situazione in cui una variabile può avere due valori diversi e fai qualcosa se è una, qualcosa di diverso se è l'altra, faresti semplicemente:

if(myVariable == FIRST_POSSIBLE_VALUE) { ... }
else { ... }

o lo faresti:

if(myVariable == FIRST_POSSIBLE_VALUE) { ... }
else if (myVariable == SECOND_POSSIBLE_VALUE) { ... }

per chiarezza, in una situazione in cui un lettore non sarebbe necessariamente in grado di dire che fanno la stessa cosa (ma l'altro se fa un'espressione "inutile")? Quindi cosa faresti? Grazie!

EDIT: Esistono in realtà opzioni molto più diverse per qualcosa del genere: operatore ternario, if-else, if-elseif, if-elseif-else, -if-else (con assert), switch. Ognuno ha il suo posto, ma è difficile decidere ..

È stato utile?

Soluzione

Non è per questo che asserire è stato fatto?

if (condition1) { ... }
else { assert(condition2); }

Questo può essere espanso anche per la logica a tre stati.

if (condition1) { ... }
elsif (condition2) { ... }
else { assert(condition3); }

L'uso di assert rende il tuo codice leggibile, facile da mantenere e chiaro. Detto questo, asserire se commenti sono quasi intercambiabili.

Altri suggerimenti

Preferisco sempre semplicemente altro quando non c'è nessun altro stato possibile della variabile (cioè, controllo per null e tutto il resto). Posso aggiungere un commento dicendo quale sia la variabile se non è la prima condizione, ma è solo nei casi in cui è simile

if(color==red){
....
}else{ //our theme only allows for red and yellow, so the color must be yellow.
....
}

Inoltre, questo fa risparmiare un po 'di tempo per il processore perché non dovrà controllare una variabile inutile (o peggio in OOP, dove il controllo di quella variabile può richiedere parecchie dereferenze, chiamate di funzione e letture di memoria)

Non faccio mai qualcosa del genere

if(file.is_open==1){
....
}else if(file.is_open==0){
....

}

poiché is_open è un valore booleano, è inutile specificare che, poiché l'unica opzione rimasta è 0, anche questo può salvare un po 'di digitazione quando è necessario refactificare il codice per utilizzare invece is_open (), poiché ora è necessario cambia una riga anziché due.

e le istruzioni 'else if' penso che dovrebbero essere trasformate in switch se c'è più di 1 'else if', a meno che ovviamente la lingua lo renda impossibile (come come C non può gestire le stringhe negli switch)

Altrimenti è un valore predefinito. Ciò significa che esiste un gran numero di possibilità per i dati o che si tratta di dati imprevisti.

Rispetto la regola di base: se esiste un parametro che può essere soddisfatto, usa else if e, in caso contrario, use else. Di solito uso qualcun altro per errori.

Uso solo if-else per i controlli booleani, ciò significa che se l'espressione non corrisponde, può esserci solo l'altro. O voglio prendere tutto con l'altro: pensalo come predefinito.

Se vuoi controllare l'enumerazione o qualcosa del genere, dovresti provare a verificarlo tramite l'istruzione switch, se possibile nella tua lingua.

In Java non è possibile utilizzare un interruttore per le stringhe. Quindi potresti usare qualcosa del genere:

if(string.equals("foo")) {
    // first case
} else if(string.equals("bar")) {
    // second case
} else {
    throw IllegalArgumentException(" ... ");
    // or log it
}

Se non sei sicuro che il tuo controllo non possa essere esteso, dovresti fornire un modo predefinito.

A volte la condizione dell'istruzione else è molto ovvia. Ad esempio

if(user.IsNew) { } else { /*in this case user.IsNew != true*/ }

Ma in altri casi, l'altro non è così ovvio ed è meglio chiarire la condizione del resto. Questa è anche una prova più futura nel caso in cui vengano aggiunte altre possibili condizioni.

Inoltre, è possibile inserire un'eccezione nell' (ultimo) altro per informare di casi non implementati. Questo può essere molto utile quando ad esempio backend e frontend sono separati e qualcuno aggiunge un nuovo valore a un enumeratore (o quando si usano le chiavi di testo una nuova chiave) si riceverà un errore quando il nuovo valore viene utilizzato per la prima volta. Se non si utilizza if else se non si vede cosa è successo e questo potrebbe rendere il debug piuttosto difficile.

if(user.SelectedStyle == Styles.Red) {
} else if(user.SelectedStyle == Styles.Basic) {
} else {
 throw new Exception("Not implemented");
}

Nel caso sopra un nuovo stile (ad esempio Style.Blue), l'applicazione genererà un'eccezione.

È davvero una questione di stile e la tua visione mentale del mondo. Il bicchiere è ENTRAMBI metà vuoto e mezzo pieno, ma è possibile ottenere le discussioni più dannose al riguardo.

Se i test booleani sono tutti dello stesso tipo, un'istruzione switch è la migliore.

In caso contrario, consiglierei di tralasciare il test aggiuntivo, ma inserisco un commento sul significato operativo di cadere in quest'ultima affermazione. Vedi il commento di Gertjan, sopra.

Quando il tuo input può essere chiaramente separato in casi distinti, ritengo sia più bello dichiarare esplicitamente quali siano questi casi, ad esempio se ti aspetti che 'n' sia un numero compreso tra 0 e 100 e hai 3 casi:

if (n >= 0 && n < 30) {
   case1();
} else if (n >=30 && n < 70) {
   case2();
} else if (n >=70 && n < 100) {
   case3();
}

in alcune situazioni il caso 'else' è utile per il controllo degli errori

} else {
   error("n should be between 0 and 100");
}

se i tuoi dati sono stati controllati per valori errati in precedenza, potrebbe esserci un caso da utilizzare altro per il caso finale, per fornire un piccolo miglioramento delle prestazioni in linguaggi come C:

} else { // (n >= 70 && n < 100)
   case3();
}

ma ciò è necessario solo a causa dell'incapacità di alcune lingue di esprimere il dominio di una funzione, in lingue in cui il dominio può essere espresso in modo chiaro, l'ottimizzatore dovrebbe aggiungere questo vantaggio in termini di prestazioni, consentendoti di essere specifico nel tuo codice, e semplificando l'aggiunta di altri casi in seguito

... ovviamente questa è un'arte, non una scienza, e in alcuni casi non riesci a seguire la regola rigida, mi trovo spesso a scrivere codice come:

if (p == NULL) {
   doSomething();
} else {
   doSomethingElse();
}

... giustificato dal fatto che è molto ovvio e implicito dalla prima condizione if a cosa serve l'altro.

else è stato inventato ed è usato per una buona ragione. Dove lo usi dovrebbe essere dettato dalla logica che stai cercando di raggiungere, non da un senso dello stile forzato.

Alcuni sostengono che sia più autocompattante usando condizioni esplicite in un else if ; tuttavia, ciò può comportare lacune nella logica di default o catturare tutte le condizioni.

Inoltre, alcuni sostengono che sarà più facile modificarlo in futuro. Questo argomento è a castello. L'uso di modelli di progettazione e la scrittura di codice modulare è qualcosa che sarà più facile da modificare in futuro, scrivere una riga non dovrebbe essere idoneo per questo tipo di affermazioni.

Dipende dalla situazione. Vuoi agire solo se vengono soddisfatti determinati criteri o esiste un caso speciale per un valore e un altro insieme di logiche per qualsiasi altro valore?

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top