Utilizzeresti le regioni all'interno di dichiarazioni di switch/enum lunghi?

Question

Recentemente mi sono trovato a dover (sì, a bisogno) definire dichiarazioni assurdamente lunghe switch e dichiarazioni enum in codice C#, ma mi chiedo cosa ritengano le persone il modo migliore per dividerle in sottosezioni logiche. Nella mia situazione, sia i valori di enum che i casi (che sono basati sui valori di enum) hanno raggruppamenti abbastanza chiari, tuttavia sono un po 'incerto su come rispecchiare questo codice.

Si noti che nel mio codice, ho circa 5 gruppi di valori compresi tra 10 e 30 valori/casi ciascuno.

Le tre opzioni vagamente ragionevoli posso prevedere sono:

1. Definire #region blocchi intorno tutti i gruppi logici di valori casi/enum all'interno della dichiarazione (opzionalmente separati da righe vuote).
2. Commenta ogni gruppo con il suo nome, con una riga vuota prima di ogni commento del nome di gruppo.
3. Non fare nulla - semplicemente lascia l'interruttore/enum come un elenco enorme di casi/valori.

Quale preferisci? Tratteresti separatamente enumerazioni e interruttori? (Questo sembrerebbe un po 'strano per me.) Ora, non direi che c'è una risposta giusta/sbagliata a questa domanda, anche se sarei comunque molto interessato a sentire quale sia il consensus generale delle opinioni.

Nota 1: Questa situazione dove potrei potenzialmente avere una dichiarazione estremamente lunga enum di 50/100 + valori è purtroppo inevitabile (e allo stesso modo con l'interruttore), dal momento che sto cercando di scrivere un lexer (tokeniser), e questo sembrerebbe quindi l'approccio più ragionevole per diversi motivi.

Nota 2: Sono pienamente consapevole del fatto che esistono già diverse domande duplicate sulla questione se utilizzare le regioni nel codice generale (per le classi di strutturazione, soprattutto), ma sento che la mia domanda qui è molto più specifico e hasn ancora stato affrontato

Answer 1

Certo, prendi nota di queste cose. Probabilmente non cambiano molto, e quando lo fanno, puoi espandere la regione, apportare le modifiche, comprimerla e passare al resto del file.

Sono lì per un motivo, usarli a proprio vantaggio.

Answer 2

Vorrei lasciarlo come un elenco enorme di casi/valori.

Answer 3

Sbarazzarsi delle enumerazioni e trasformarle in oggetti. Potresti quindi chiamare metodi sui tuoi oggetti e mantenere il codice separato, manutenibile e non un incubo.

Ci sono pochissimi casi in cui è effettivamente necessario utilizzare un enum anziché un oggetto e a nessuno piacciono le dichiarazioni di switch lunghe.

Answer 4

Se alcuni casi hanno lo stesso blocco di codice, utilizzando lo schema di progettazione della strategia, è possibile rimuovere il blocco switch. Questo può creare molte classi, ma mostrerà quanto sia davvero complesso e dividere la logica in classi più piccole.

Answer 5

Si potrebbe anche avere un dizionario < [your_enum_type], azione> (o Func invece di azione) o qualcosa del genere (considerando che le proprie funzioni hanno una firma simile).Poi si potrebbe invece di utilizzare un interruttore, invece di:

 switch (item) 
     { 
      case Enum1: func1(par1, par2) 
       break; 
      case Enum2: func2(par1, par2) 
       break; 
     } 

si potrebbe avere qualcosa di simile:

public class MyClass 
{ 
    Dictionary<int, Action<int, int>> myDictionary; 
    //These could have only static methods also 
    Group1Object myObject1; 
    Group2Object myObject2; 

    public MyClass() 
    { 
     //Again, you wouldn't have to initialize if the functions in them were static 
     myObject1 = new Group1Object(); 
     myObject2 = new Group2Object(); 
     BuildMyDictionary(); 
    } 

    private Dictionary<int, Action<int, int>> BuildMyDictionary() 
    { 
     InsertGroup1Functions(); 
     InsertGroup2Functions(); 
     //... 
    } 

    private void InsertGroup2Functions() 
    { 
     myDictionary.Add(1, group2.AnAction2); 
     myDictionary.Add(2, group2.AnotherAction2); 
    } 

    private void InsertGroup1Functions() 
    { 
     myDictionary.Add(3, group1.AnAction1); 
     myDictionary.Add(4, group1.AnotherAction1); 
    } 


    public void DoStuff() 
    { 
     int t = 3; //Get it from wherever 
     //instead of switch 
     myDictionary[t](arg1, arg2); 
    } 
} 

Answer 6

Ecco una buona scorciatoia per le persone che utilizzano le regioni.

mi è stato il passaggio tra Eclipse e Visual Studio quando ho provato per lo schermo intero in VS premendo

Ctrl-M-M

ed ecco, la regione chiusa e ampliato!