È una cattiva pratica avere un caso di commutazione in un caso di commutazione?

Question

È una cattiva pratica avere un caso di commutazione in un interruttore? Se sì, quali sono le alternative? Non voglio veramente usare if/else if se non ne ho bisogno.

Invece di fare un po 'come:

if((this == 1) && (that == 1)){ //something } 
else if((this == 1) && (that == 2)){ //something } 
else if((this == 2) && (that == 3)){ //something } 

Stavo pensando lungo le linee di:

switch(this){ 
    case 1: 
     switch(that){ 
      case 1: 
       // something 
      break; 
      .... 
     } 
    break; 
    .... 
} 

sembra proprio davvero sbagliato per me. Non sbagliato nella sintassi ma sbagliato in termini di pratica corretta.

Answer 1

Evitare seguente approccio

switch(id) 
{ 
    case 1: 
    { 
     switch (subid) 
     { 
      case 4: 
       // nested code 
     } 
    } 
    case 2: 
     // some code 
} 

L'approccio preferibile e migliorare il codice spostando sezione annidato in un metodo

switch(id) 
{ 
    case 1: 
     SubSwtich(subid); 
     break; 
    case 2: 
     // some code 
} 

function SubSwtich(int subid) 
{ 
     switch (subid) 
     { 
      case 4: 
       // nested code 
     } 
} 

Answer 2

lo considererei una cattiva pratica. nella maggior parte dei casi questo è illeggibile.

è possibile estrarre i "sub" switch-cases ai metodi.

Answer 3

È una cattiva pratica avere funzioni enormi che fanno molte cose diverse. Se hai un caso di commutazione in un caso di commutazione, ciò suggerisce che la tua funzione è probabilmente troppo grande e dovresti prendere in considerazione la possibilità di suddividerla in blocchi più piccoli e più facili da capire.

Ma non ci sono regole rigide; tutto dipende dallo scenario esatto.

Answer 4

Cattiva pratica? No! Un potenziale dolore quando si tratta di risoluzione dei problemi, probabilmente! Scopri cosa puoi fare per trasformare tutte le "opzioni" in qualcosa di più organizzato e comunemente connesso. Forse anche scrivere la propria funzione utilizzando l'overloading del metodo determinato dal numero di parametri inviati.

Dai uno sguardo allo at this SO post e vedi se ti dà qualche idea.

Answer 5

È necessario suddividere il codice in routine diverse a seconda dell'istruzione switch e nella routine è possibile continuare a utilizzare anche il caso switch. Proprio come seguire

private void Switch(int value) 
    { 

     switch (value) 
     { 
      case 1: 
       SwitchNest(value); 
       break; 
      case 2: 
       break; 
     } 
    } 

    private void SwitchNest(int value) 
    { 
     switch (value) 
     { 
      case 1: 
       SwitchOtherMethod(value); 
       break; 
      case 2: 
       break; 
     } 
    } 

Answer 6

Se si rende il codice più difficile da leggere, allora è male pratica.

Se questo è il caso nel vostro esempio, dipende da voi decidere, ma in generale direi che probabilmente sarebbe il caso.

hai chiesto di alternative ...

1. estrarre alcune del codice in un sub-funzioni. Ad esempio:

   case 'foo' : 
       myVar = 'blah'; 
       break; 
   case 'bar' : 
       myVar = secondLevelFunction(); 
       break; 
   

   Qui, il secondLevelFunction() contiene l'ulteriore switch() dichiarazione in cui ogni case restituisce un valore per myVar.

2. Utilizzare la mappatura dell'array.Ad esempio:

   var mapper = {'foo':'blah', 'bar':'bibble', etc}; 
   
   //now, instead of a big switch(input) { .... } block that sets myVar 
   //for each option, you can just set it directly in a single line, like so: 
   var myVar = mapper[input]; 
   

Inoltre, se siete alla ricerca di misure concrete di qualità del codice, si dovrebbe conoscere Cyclomatic Complexity. Questa è una misura di quanto sia complessa una funzione. La misurazione è presa considerando quanti "punti decisionali" ha la funzione. Ogni case, if, loop, ecc. È un "punto di decisione". Più hai, più complessa è la tua funzione.

complessità ciclomatica è stronly legata alla qualità del codice e le buone pratiche di codifica, quindi se la vostra funzione ha un punteggio elevato CC (che probabilmente farà se si dispone di più nidificati switch blocchi), allora è un segno di scarsa qualità del codice . Entrambe le soluzioni alternative che ho descritto sopra possono aiutare con questo. Lascio a te di leggere di più su CC.

Ovviamente le soluzioni alternative dovrebbero essere adattate alle vostre esigenze, ma si spera che vi diano alcune idee.