Switch case per una condizione

Il fatto che la funzione sia chiamata trackAnalyticsEvent mi sembra che farà qualcosa di più del semplice controllo. In ogni caso (gioco di parole) un caso non sarebbe rilevante dal momento che sarebbe solo un semplice scenario if-else.

Ci sono situazioni in cui oggi ho un caso, ma so che aggiungerò altri casi domani.

Ci sono situazioni in cui molte funzioni seguono lo stesso schema, alcune terminano con una dozzina di casi, alcuni terminano con un caso.

Entrambe sono situazioni in cui vorrei usare una dichiarazione di un caso.

Se questo è un aggiornamento intermedio in un'attività più grande, e ha un commento (con una data) che dice che più casi verranno aggiunti più tardi quando tale e-tale sarà pronto, quindi direi che è OK. Ad esempio, se prevedi di supportare diversi dispositivi hardware intercambiabili e ha solo scritto il codice per il primo fino ad ora, allora va bene.

Ma se non ci sono piani immediati per casi aggiuntivi, dovrebbe usare invece un blocco If.

Inoltre, se si tratta di una modifica al codice esistente, potrebbero essersi verificati diversi casi in precedenza e li ha condensati / refactati. In una situazione del genere, ha ottenuto buoni risultati consolidando il codice, ma ha trascurato il fatto che avrebbe dovuto cambiare l'opzione Passa a un caso in cui rimaneva solo un caso singolo, il che sarebbe una semplice svista da fare. Vorrei lasciare un commento del tipo "non dimenticare che, dopo aver rimosso gli altri casi, puoi anche semplificarlo in un'istruzione If". Questo ha la connotazione che è sulla strada giusta, quindi è più incoraggiante.

Un'istruzione switch e una catena di if s generano le stesse istruzioni a livello di macchina. Scegli l'uno o l'altro in base alla chiarezza del codice.

Hai zero guadagni sull'espressività (e io potrei dire che hai una perdita) se crei un switch con un singolo caso.

Hai anche zero guadagni sulla velocità di codifica nel caso in cui sai che "in futuro" ci saranno più casi, dal momento che non ci vorrà più di qualche secondo per trasformare il tuo if in un %codice%.

Alcune altre risposte ci dicono che un interruttore segnala che "questo potrebbe crescere". Questo semplicemente va contro SOLID, in quanto non rispetta Open-Closed Principle , perché se quel codice è pronto, l'unico modo per modificarne il comportamento è cambiarlo.

Direi che è una questione di contesto.

Sono perfettamente contento di vedere un interruttore o un if.

Ma, se vedo un interruttore, penserò che potrebbe crescere.

Se vedo un if, non penserò che questo potrebbe crescere.

Quindi: se è qualcosa che potrebbe crescere, è perfetto come interruttore (anzi, preferirei questo). Se è qualcosa che non lo farà, suggerirei di cambiarlo in un if.

Per lo meno, chiedi informazioni sull'intento alla base dell'interruttore del caso singolo.

Per inciso, non mi aspetto che anche lo sviluppatore più inesperto possa essere confuso da un singolo switch: lo userei come una buona lezione su come scrivere (e leggere) il codice informativo facendo riferimento al potrebbe crescere? treno di pensieri.