Perché le persone sono così fortemente contrarie ai tag #region nei metodi?

Ho sentito molto parlare di abbreviare i metodi e ho sentito molti programmatori dire che usare i tag #region all'interno di un metodo è un segno sicuro che è troppo lungo e dovrebbe essere riformulato in più metodi. Tuttavia, mi sembra che ci siano molti casi in cui la separazione del codice con i tag #region all'interno di un metodo è la soluzione superiore per il refactoring in più metodi.

Supponiamo di avere un metodo il cui calcolo può essere separato in tre fasi piuttosto distinte. Inoltre, ognuna di queste fasi è rilevante solo per il calcolo di questo metodo, e quindi estrarle in nuovi metodi non ci consente di riutilizzare il codice. Quali sono, quindi, i vantaggi dell'estrazione di ogni fase nel suo metodo? Per quanto ne so, tutto ciò che otteniamo è una certa leggibilità e un ambito variabile separato per ogni fase (che aiuterà a impedire che le modifiche di una particolare fase interrompano accidentalmente un'altra fase).

Tuttavia, entrambi questi possono essere raggiunti senza estrarre ciascuna fase nel proprio metodo. I tag di regione ci consentono di comprimere il codice in un modulo che è altrettanto leggibile (con l'ulteriore vantaggio che non dovremo più lasciare il nostro posto in questo file se dovessimo decidere di espandere ed esaminare il codice) e semplicemente racchiudendo ogni fase in {}crea il proprio ambito con cui lavorare.

Il vantaggio di farlo in questo modo è che non inquiniamo l'ambito di classe con tre metodi che sono in realtà rilevanti solo per il funzionamento interno di un quarto metodo. Il refactoring immediato di un metodo lungo in una serie di metodi brevi mi sembra il riutilizzo del codice equivalente all'ottimizzazione prematura; stai introducendo ulteriore complessità al fine di affrontare un problema che in molti casi non si presenta mai. È sempre possibile estrarre una delle fasi nel proprio metodo in un secondo momento in caso si presenti l'opportunità di riutilizzare il codice.

Pensieri?

Tutto ciò di cui dovresti preoccuparti è che il tuo codice sia utilizzabile, non riutilizzabile. Una scimmia può trasformare il codice utilizzabile in codice riutilizzabile, se ci sono delle trasformazioni da fare.

L'argomento "Ne ho bisogno solo qui" è scarso, per dirla educatamente. La tecnica che stai descrivendo viene spesso definita tecnica dei titoli ed è generalmente disapprovata.

1. Non è possibile testare le regioni, ma è possibile testare metodi veri in modo isolato.
2. Le regioni sono commenti, non elementi sintattici. Nel peggiore dei casi, la nidificazione delle regioni e dei blocchi si contraddicono a vicenda. Dovresti sempre cercare di rappresentare la semantica della tua struttura con gli elementi sintattici della lingua che stai usando.
3. Dopo aver eseguito il refactoring ai metodi, non è più necessario piegare per leggere il testo. Si potrebbe guardare il codice sorgente in qualsiasi strumento che non abbia la piegatura, come un terminale, un client di posta, una vista Web per il VCS o un visualizzatore di differenze.
4. Dopo il refactoring ai metodi, il metodo risultante è almeno buono come con le regioni, inoltre è più semplice spostare le singole parti.
5. Il principio di responsabilità singola suggerisce che qualsiasi unità dovrebbe avere un solo compito e un solo compito. Il compito del metodo "principale" è quello di comporre i metodi "helper" per ottenere il risultato desiderato. I metodi "helper" risolvono un problema discreto e semplice in modo isolato. La classe che contiene tutti questi metodi dovrebbe inoltre svolgere una sola attività e contenere solo i metodi relativi a tale attività. Quindi i metodi helper o appartengono all'ambito della classe, o il codice non dovrebbe essere nella classe in primo luogo, ma almeno in un metodo globale o, meglio ancora, dovrebbe essere iniettato .

Anche rilevante: i pensieri di Jeff Atwoods sulla piegatura del codice

Non sono le regioni nei metodi che sono il problema, ma il caso in cui c'è la necessità (o persino un uso) di mettere le regioni nei metodi.

Avendo dovuto eseguire il debug di molti metodi di 200-300 linee, posso dirti che non lo vorrei su nessuno. Se stai scrivendo e cercando il tuo codice va bene, fai quello che vuoi. Ma una volta che qualcun altro lo guarda, dovrebbe essere immediatamente chiaro cosa sta facendo un metodo.

"Prima prende le cose, e poi le fa girare, quindi se hanno bisogno di ronzio lo fa, altrimenti controlla se sono blu e inverte il loro valore di Copernico. Quindi, se la seconda cosa è maggiore della prima cosa, noi è necessario prendere la scatola del succo e inserirla ... "

No, non è abbastanza buono. Spezzalo in tutte le regioni che vuoi, ma sto ancora scuotendo la testa solo a pensarci.

Se entri in metodi ottieni molti vantaggi:

• Comprensione più chiara di ciò che sta accadendo dove, anche solo attraverso il nome del metodo. E tu sei sbagliato che un metodo non può essere completamente documentato - aggiungere il blocco di documentazione (hit ///) e inserire la descrizione, parametri, tipo di ritorno, e anche exception, example, remarksnodi per il dettaglio questi scenari. Ecco dove va, ecco a cosa serve!
• Non ci sono effetti collaterali o problemi di scoping. Si può dire che si dichiarano tutte le variabili in un ambito secondario con {}, ma devo controllare tutti i metodi per assicurarmi di non "imbrogliare"? E 'questo dodgyObjectche sto usando qui solo perché usato in questa regione, o si è arrivati da qualche altra parte? Se fossi nel mio metodo sarei facilmente in grado di vedere se mi è stato passato o se l'ho creato da solo (o meglio, se lo hai creato).
• Il mio registro eventi mi dice in quale metodo si è verificata un'eccezione. Sì, potrei essere in grado di trovare il codice offensivo con un numero di riga, ma conoscere il nome del metodo (specialmente se li ho nominati correttamente) mi dà un'ottima indicazione di cosa è successo e cosa è andato storto. "Oh, il TurnThingsUpsideDownmetodo ha fallito - probabilmente sta fallendo mentre si trasforma una brutta cosa" è molto meglio di "Oh, il DoEverythingmetodo ha fallito - avrebbero potuto essere 50 cose diverse e dovrò scavare per un'ora per trovarlo" .

Tutto questo prima di qualsiasi preoccupazione di riusabilità o improvvisabilità. I metodi correttamente separati ovviamente facilitano il riutilizzo e consentono anche di sostituire facilmente un metodo che non funziona (troppo lento, troppo difettoso, dipendenza modificata ecc.). Hai mai provato a refactoring uno di questi metodi enormi? Non c'è modo di sapere che ciò che stai cambiando non avrà alcun effetto su altro.

Incapsulare correttamente la logica in metodi di dimensioni ragionevoli. So che è facile per loro sfuggire di mano, e sostenere che non vale la pena riprogettare una volta a quel punto è un altro problema. Ma devi accettare il fatto che non ci sono danni e almeno potenziali benefici nell'avere metodi incapsulati, scritti in modo pulito e progettati semplicemente.

Se il tuo metodo è abbastanza complesso da poter essere separato in tre fasi distinte, allora non dovrebbero essere solo tre metodi separati ... ma il tuo metodo dovrebbe in effetti essere una classe separata, dedicata a quel calcolo.

"Ma poi la mia classe avrà un solo metodo pubblico!"

Hai ragione, e non c'è niente di sbagliato in questo. L'idea del principio della responsabilità singola è che la tua classe fa una cosa .

La tua classe può chiamare ciascuno dei tre metodi a turno e restituire il risultato. Una cosa.

Come bonus, ora il tuo metodo è testabile perché non è più un metodo privato.

Ma non importa una classe; in realtà dovresti averne quattro : una per ciascuna delle parti del tuo metodo, più una che prende ciascuna delle tre come dipendenza e le chiama nell'ordine corretto, restituendo il risultato.

Questo rende le tue lezioni ancora più testabili. Ti consente anche di cambiare facilmente uno di quei tre pezzi. Basta scrivere una nuova classe che eredita da quella precedente e sovrascrivere il comportamento modificato. Oppure crea un'interfaccia per il comportamento di ciascuno dei tuoi tre pezzi; e quindi per sostituirne uno, basta scrivere una nuova classe che implementa quell'interfaccia e sostituirla con quella vecchia nella configurazione del contenitore di iniezione delle dipendenze.

Che cosa? Non stai usando l'iniezione di dipendenza? Bene, probabilmente non hai ancora visto la necessità, perché non stai seguendo il principio della responsabilità singola. Una volta iniziato, scoprirai che il modo più semplice per dare a ciascuna classe le sue dipendenze è usare un contenitore DI.

MODIFICA :

OK, mettiamo da parte la domanda di refactoring. Lo scopo #regionè nascondere il codice , che significa principalmente codice che non deve essere modificato in nessuna circostanza normale. Il codice generato è il miglior esempio. Dovrebbe essere nascosto nelle regioni perché normalmente non è necessario modificarlo. Se necessario, l'atto di espandere una regione ti dà un po 'di avvertimento in stile "Here be dragons" per assicurarti di sapere cosa stai facendo.

Pertanto direi #regionche non dovrebbe essere usato nel mezzo di un metodo. Se apro un metodo, voglio vedere il codice. L'uso di #region mi dà un altro livello di nascondiglio di cui non ho bisogno, e questo diventa un fastidio: ho spiegato il metodo ... e ancora non riesco a vedere alcun codice.

Se sei preoccupato per le persone che vedono la struttura del metodo (e ti rifiuti di riformattarlo), quindi aggiungi commenti banner come questo:

//
// ---------- COMPUTE SOMETHING OR OTHER ----------
//

Questi aiuteranno qualcuno che naviga nel codice a vedere le singole parti del tuo metodo senza dover affrontare l'espansione e la compressione dei #regiontag.

Penso che l'esempio che dai nel tuo argomento sia meno su YAGNI (non ne avrai bisogno) e più sulla scrittura di un codice di qualità adeguato che sia facilmente gestibile.

Nei primi corsi di programmazione apprendiamo che se un metodo è lungo 700 LOC, è probabilmente troppo grande e sicuramente sarebbe un dolore enorme provare e debug.

In secondo luogo, se scrivo i metodi A, B e C che vengono utilizzati solo all'interno del metodo D, allora posso più facilmente test unitario AB e C indipendentemente da D, consentendo test unitari più robusti in tutti e 4 i metodi.

Supponiamo di avere un metodo il cui calcolo può essere separato in tre fasi piuttosto distinte. Inoltre, ognuna di queste fasi è rilevante solo per il calcolo di questo metodo, e quindi estrarle in nuovi metodi non ci consente di riutilizzare il codice. Quali sono, quindi, i vantaggi dell'estrazione di ogni fase nel suo metodo? Per quanto ne so, tutto ciò che otteniamo è una certa leggibilità e un ambito variabile separato per ogni fase (che aiuterà a impedire che le modifiche di una particolare fase interrompano accidentalmente un'altra fase).

Questi sono due vantaggi. Ma quello importante, secondo me, è la debuggabilità . Se devi rintracciare quel codice, è molto più semplice riuscire a superare due delle tre sezioni e tracciare solo in quella a cui tieni. Rifattorizzare in metodi più piccoli lo consente; i tag della regione no.

La mia regola personale è che se un metodo è più lungo di uno schermo, diciamo 40 righe, è troppo lungo. Se una classe è più lunga di 500 righe, è troppo grande. A volte infrange queste regole, a volte anche da un grande multiplo, ma generalmente me ne pento entro l'anno.

Anche un metodo che va dalle 20 alle 30 linee sta diventando un po 'lungo nella maggior parte dei casi. Quindi direi che usare le regioni in un metodo è di solito una cattiva idea, semplicemente perché non avrebbe quasi mai senso comprimere una regione di 20-30 linee in più sottoregioni.

La scomposizione di funzioni lunghe secondo questa definizione ha almeno due vantaggi:

1. Puoi dare un nome a ciò che stanno facendo quelle sotto-funzioni, il che chiarisce il tuo pensiero attuale e semplifica il compito dei manutentori successivi.

2. La scomposizione in funzioni più piccole ti costringe a passare solo i parametri di cui hanno bisogno le funzioni più piccole, quindi l'ambito dei dati che richiedono e modificano è molto chiaro. Ciò presuppone che non si stia accedendo e modificando lo stato dell'oggetto in un centinaio di diverse funzioni foglia, che scoraggerei anche.

Nella mia esperienza, queste regole producono codice che è più facile da scrivere senza commettere errori comuni e può essere compreso e modificato in seguito senza interrompere comportamenti sottili. Non importa se la persona che deve capire / modificare il codice è qualcun altro o me stesso dopo aver dormito e dimenticato tutto.

Quindi considererei le regioni nei metodi come un "odore di codice" che indica che vengono applicate pratiche insostenibili. Come sempre, potrebbero esserci delle eccezioni, ma si verificano così raramente che quasi non vale la pena discutere.

Eccoci di nuovo ... Ci sono molti altri argomenti qui sui programmatori che sono finiti nella stessa discussione.

Indichi alcuni argomenti molto interessanti relativi alle funzioni brevi. Non è un'affermazione popolare, ma io sono con te su questo . Dopo averne discusso spesso prima, mi sembra che la discussione di solito si riduca al fatto che ti concentri principalmente sull'incapsulamento corretto o porti al massimo lo sviluppo guidato dai test. Questi sono i due contendenti principali in quella che sembra essere l'ennesima guerra santa, e temo che siamo dalla parte del potere.

Tuttavia ...

La soluzione secondo me sicuramente non sta avvolgendo le "fasi" nelle regioni. La piegatura del codice viene utilizzata per spazzare il codice sotto il tappeto. Lascia il codice lì com'è, potrebbe ricordarti che potresti voler riformattare in un secondo momento! Per collegarlo a un argomento nella tua domanda: come potrai vedere un'opportunità per il riutilizzo del codice se non vedi alcun codice? Lunghi segmenti di codice dovrebbero essere esattamente questo, una spina nell'occhio che ti fa venir voglia di riformattarlo.

Come sostituto appropriato per le regioni, suggerisco di usare i paragrafi di codice come Alex Papadimoulis li nomina in un commento . In realtà potresti già utilizzare un approccio simile. Sono semplicemente blocchi di codice con un'intestazione di commento, che spiega cosa fa l'intero blocco. Hai la leggibilità delle funzioni, ma sei in grado di usare frasi inglesi normalmente distanziate e non perdi alcun incapsulamento.

Anche se sono d'accordo che di solito è meglio refactificare il codice piuttosto che usarlo #region, non è sempre possibile.

Per supportare questa affermazione, lasciami fare un esempio.

class Foo : IComparable
{
  private String name;
  private int foo;
  private Bar bar;

  public int CompareTo(Foo other)
  {
#region Ascending on name
     if (this.name < other.name) return -1;
     if (this.name > other.name) return 1;
#endregion
#region Usual order on bar
     int compBar = bar.compareTo(other.bar);
     if (compBar != 0) return compBar;
#endregion
#region Descending on foo
     if (this.foo > other.foo) return -1;
     if (this.foo < other.foo) return 1;
#endregion
     return 0; // equal
  }

È facile regolare nuovamente le regioni per modificare l'ordine o estenderle quando vengono aggiunti campi aggiuntivi alla classe. Sono comunque necessari commenti per vedere rapidamente come dovrebbe funzionare l'ordinamento. E soprattutto: non vedo come il refactoring aiuterà la leggibilità in questo caso.

Tuttavia, tali eccezioni sono rare. Di solito è possibile refactoring, come dicono molte altre risposte.

Non credo che ci sia una sola risposta al motivo per cui determinate persone o team decidono di non utilizzare, #regionma se dovessi elencarne alcuni, questo sarebbe il motivo principale che ho visto.

• I nomi e l'ordine delle regioni rendono più esplicito l'ordinamento e l'organizzazione del codice che impone uno stile particolare che può diventare una fonte di contesa e di bikeshedding.
• La maggior parte dei concetti non si adatta perfettamente a un piccolo numero di regioni. In genere si inizia con regioni per modificatori di accesso pubblici , privati , quindi forse per tipo di membro (es. Metodo, proprietà, campo) ma poi per quanto riguarda i costruttori che abbracciano quei modificatori, varietà statiche di tutti questi, membri protetti, membri interni, interni protetti membri, membri dell'interfaccia impliciti, eventi, ecc. Alla fine avresti classi ben progettate in cui hai un singolo o un metodo in ogni regione a causa della categorizzazione granulare.
• Se sei in grado di mantenere pragmatico e raggruppare le cose in tre o quattro tipi costanti di regioni, questo potrebbe funzionare, ma quale valore aggiunge? Se stai progettando bene le classi, non dovresti davvero dover scorrere tra le pagine di codice.
• Come accennato in precedenza, le regioni possono nascondere un brutto codice che può renderlo meno problematico di quello che è. Mantenerlo come un mal di occhio può aiutare a farlo affrontare.