Come ti senti riguardo al ripiegamento del codice?[Chiuso]

https://stackoverflow.com/questions/5916

08-06-2019
|

Domanda

Per quelli di voi che lavorano nell'ambiente Visual Studio, cosa ne pensate di racchiudere il vostro codice in #regions?(o se qualsiasi altro IDE ha qualcosa di simile...)

Soluzione

9 volte su 10, la piegatura del codice significa che non hai utilizzato il file Principio SoC per quello che vale.
Più o meno sento la stessa cosa per le lezioni parziali.Se hai un pezzo di codice che ritieni sia troppo grande, devi suddividerlo in parti gestibili (e riutilizzabili), non nasconderlo o dividerlo.
Ti morderà la prossima volta che qualcuno avrà bisogno di cambiarlo e non potrà vedere la logica nascosta in un metodo mostruoso di 250 righe.

Ogni volta che puoi, estrai del codice dalla classe principale e inseriscilo in una classe helper o factory.

foreach (var item in Items)
{
    //.. 100 lines of validation and data logic..
}

non è leggibile come

foreach (var item in Items)
{
    if (ValidatorClass.Validate(item))
        RepositoryClass.Update(item);
}

I miei $ 0,02 comunque.

Altri suggerimenti

Se ne è parlato su Codificare l'orrore.

La mia convinzione personale è che siano utili, ma come qualsiasi cosa in eccesso può essere troppo.

Lo uso per ordinare i miei blocchi di codice in:
Enumerazioni
Dichiarazioni
Costruttori
Metodi
Gestori di eventi
Proprietà

A volte potresti ritrovarti a lavorare in un team in cui le #regioni sono incoraggiate o richieste.Se sei come me e non sopporti di scherzare con il codice piegato, puoi disattivare la struttura per C#:

Opzioni -> Editor di testo -> C# -> Scheda Avanzate
Deseleziona "Accedi alla modalità struttura all'apertura dei file"

Utilizzo #Region per nascondere il codice generato automaticamente brutto e inutile, che in realtà appartiene alla parte generata automaticamente della classe parziale.Ma quando si lavora con vecchi progetti o progetti aggiornati, non sempre si ha questo lusso.

Come per gli altri tipi di piegatura, piego sempre Functions.Se dai un nome giusto alla funzione, non dovrai mai guardarci dentro a meno che tu non stia testando qualcosa o (ri)scrivendolo.

Anche se capisco il problema che Jeff, et.al.avere con le regioni, quello che ho non capire è perché colpire CTRL+M,CTRL+l espandere tutte le regioni in un file è molto difficile da gestire.

Io uso Compagno di testo (Solo Mac) che ha la piegatura del codice e lo trovo davvero utile per le funzioni di piegatura, so cosa fa la mia funzione "getGet", non ho bisogno che occupi 10 righe di spazio sullo schermo davvero prezioso.

Non lo uso mai per nascondere un ciclo for, un'istruzione if o simili a meno che non mostri il codice a qualcun altro dove nasconderò il codice che hanno visto per evitare di mostrare lo stesso codice due volte.

Preferisco le classi parziali rispetto alle regioni.

L’uso estensivo delle regioni da parte di altri mi dà anche l’impressione che qualcuno, da qualche parte, stia violando il principio di responsabilità unica e stia cercando di fare troppe cose con un unico oggetto.

@Tom

Vengono fornite classi parziali in modo che tu possa separare il codice generato automaticamente dallo strumento da eventuali personalizzazioni che potresti dover apportare dopo che la generazione del codice ha fatto la sua parte.Ciò significa che il tuo codice rimane intatto dopo aver eseguito nuovamente il codegen e non viene sovrascritto.Questa è una buona cosa.

Non sono un fan delle lezioni parziali: cerco di sviluppare le mie lezioni in modo tale che ogni classe abbia un unico problema molto chiaro di cui è responsabile.A tal fine, non credo che qualcosa con una responsabilità chiara debba essere suddiviso su più file.Ecco perché non mi piacciono le lezioni parziali.

Detto questo, sono indeciso riguardo alle regioni.Per la maggior parte non li uso;tuttavia, lavoro ogni giorno con codice che include regioni: alcune persone vanno molto pesante con loro (ripiegando i metodi privati in una regione e poi ogni metodo ripiegato nella propria regione), e alcune persone li usano leggeri (ripiegando enumerazioni, ripiegare gli attributi, ecc.).La mia regola generale, per ora, è che inserisco il codice nelle regioni solo se (a) è probabile che i dati rimangano statici o non verranno toccati molto spesso (come le enumerazioni), o (b) se ci sono metodi che sono implementati per necessità a causa della sottoclasse o dell'implementazione di metodi astratti, ma, ancora una volta, non verranno toccati molto spesso.

Le regioni non devono mai essere utilizzate all'interno dei metodi.Possono essere utilizzati per raggruppare metodi ma ciò deve essere gestito con estrema cautela affinché il lettore del codice non impazzisca.Non ha senso piegare i metodi in base ai loro modificatori.Ma a volte la piegatura può aumentare la leggibilità.Per es.potrebbe essere utile raggruppare alcuni metodi che usi per risolvere alcuni problemi quando usi una libreria esterna e che non vorrai visitare troppo spesso.Ma il programmatore deve sempre cercare soluzioni come avvolgere la libreria con classi appropriate in questo particolare esempio.Quando tutto il resto fallisce, usa la piegatura per migliorare la leggibilità.

Questa è solo una di quelle sciocche discussioni che non portano da nessuna parte.Se ti piacciono le regioni, usale.In caso contrario, configura il tuo editor per disattivarli.Lì sono tutti felici.

Il ripiegamento delle regioni andrebbe bene se non dovessi mantenere manualmente i raggruppamenti delle regioni in base alle funzionalità del mio codice che sono intrinseche alla lingua.Ad esempio, il compilatore sa già di essere un costruttore.Il modello di codice dell'IDE sa già che si tratta di un costruttore.Ma se voglio vedere una vista del codice in cui i costruttori sono raggruppati insieme, per qualche motivo devo riaffermare il fatto che queste cose sono costruttori, mettendole fisicamente insieme e poi creando un gruppo attorno ad esse.Lo stesso vale per qualsiasi altro modo di suddividere una classe/struttura/interfaccia.Cosa succede se cambio idea e voglio vedere i contenuti pubblici/protetti/privati prima separati in gruppi e poi raggruppati per tipo di membro?

Utilizzare le regioni per delimitare le proprietà pubbliche (ad esempio) è altrettanto negativo quanto inserire un commento ridondante che non aggiunge nulla a ciò che è già distinguibile dal codice stesso.

Ad ogni modo, per evitare di dover utilizzare le regioni a tale scopo, ho scritto un componente aggiuntivo IDE di Visual Studio 2008 gratuito e open source chiamato Ora.Fornisce automaticamente una visualizzazione raggruppata, rendendo molto meno necessario mantenere il raggruppamento fisico o utilizzare le regioni. Potresti trovarlo utile.

In genere lo trovo quando ho a che fare con codice come Events in C# dove ci sono circa 10 righe di codice che in realtà sono solo parte di una dichiarazione di evento (la classe EventArgs, la dichiarazione del delegato e la dichiarazione di evento) Mettendo una regione attorno a loro e poi piegandole in questo modo lo rende un po' più leggibile.

Penso che sia uno strumento utile, se usato correttamente.In molti casi, ritengo che i metodi, le enumerazioni e altre cose che vengono spesso ripiegate dovrebbero essere piccole scatole nere.A meno che tu non debba guardarli per qualche motivo, il loro contenuto non ha importanza e dovrebbe essere il più nascosto possibile.Tuttavia, non abbandono mai metodi privati, commenti o classi interne.Metodi ed enumerazioni sono davvero le uniche cose che piego.

Il mio approccio è simile a quello di alcuni altri qui, utilizzando le regioni per organizzare i blocchi di codice in costruttori, proprietà, eventi, ecc.

C'è un eccellente set di macro VS.NET di Roland Weigelt disponibile nel suo post sul blog, Migliore supporto per la tastiera per #region...#endregion.Li uso da anni, mappando ctrl+.per comprimere la regione corrente e ctrl++ per espanderla.Scopri che funziona molto meglio della funzionalità VS.NET predefinita che piega/spiega tutto.

Personalmente utilizzo sempre #Regions.Trovo che mi aiuti a mantenere cose come proprietà, dichiarazioni, ecc. separate le une dalle altre.

Probabilmente anche questa è una buona risposta!

Codificare l'orrore

Modificare:Cavolo, Pat mi ha preceduto!

Anch'io preferisco le #regioni, ma un vecchio collega non sopportava che le cose fossero nascoste.Ho capito il suo punto quando ho lavorato su una pagina con 7 #regioni, di cui almeno 3 generate automaticamente e con lo stesso nome, ma in generale penso che siano un modo utile per dividere le cose e tenere tutto meno ingombrante.

Non ho davvero problemi con l'utilizzo di #region per organizzare il codice.Personalmente, solitamente installo regioni diverse per cose come proprietà, gestori di eventi e metodi pubblici/privati.

Eclipse fa parte di questo in Java (o PHP con plugin) da solo.Ti consente di piegare funzioni e simili.Tendo a piacermi.Se so cosa fa una funzione e non ci sto lavorando, non ho bisogno di guardarla.

Emacs ha una modalità minore pieghevole, ma la avvio solo occasionalmente.Soprattutto quando lavoro su qualche mostruosità ereditata da un altro fisico che evidentemente aveva meno istruzioni o si prendeva meno cura delle sue pratiche di codifica.

Utilizzo delle regioni (o altrimenti del codice pieghevole) Dovrebbe non avere nulla a che fare con gli odori di codice (o nasconderli) o qualsiasi altra idea di nascondere il codice che non vuoi che le persone vedano "facilmente".

Le regioni e il ripiegamento del codice mirano davvero a fornire un modo per raggruppare facilmente sezioni di codice che possono essere compresse/piegate/nascoste per ridurre al minimo la quantità di "rumore" estraneo attorno a ciò su cui stai attualmente lavorando.Se imposti le cose correttamente (ovvero dai un nome utile alle tue regioni, come il nome del metodo contenuto), puoi comprimere tutto tranne la funzione che stai attualmente modificando e mantenere comunque un certo livello di contesto senza dover effettivamente vedere l'altra righe di codice.

Probabilmente dovrebbero esserci alcune linee guida sulle migliori pratiche relative a queste idee, ma utilizzo ampiamente le regioni per fornire una struttura standard ai miei file di codice (raggruppo eventi, campi a livello di classe, proprietà/metodi privati, proprietà/metodi pubblici).Ogni metodo o proprietà dispone anche di una regione, dove il nome della regione è il nome del metodo/proprietà.Se ho un sacco di metodi sovraccarichi, il nome della regione è la firma completa e quindi l'intero gruppo è racchiuso in una regione che è solo il nome della funzione.

Personalmente odio le regioni.Secondo me, l'unico codice che dovrebbe trovarsi nelle regioni è il codice generato.Quando apro il file inizio sempre con Ctrl+M+O.Questo si ripiega a livello di metodo.Quando hai regioni non vedi altro che nomi di regioni.

Prima di effettuare il check-in, raggruppo i metodi/campi in modo logico in modo che sembri ok dopo Ctrl+M+O.Se hai bisogno di regioni, hai troppe code nella tua classe.Trovo anche che questo sia molto comune.

regione ThisLooksLikeWellOrganizedCodeBecauseIUseRegions

// totale spazzatura, nessuna struttura qui

regione finale

Enumerazioni

Proprietà

.tori

Metodi

Gestori di eventi

Questo è tutto ciò per cui utilizzo le regioni.Non avevo idea che potessi usarli all'interno dei metodi.

Sembra un'idea terribile :)

IL Codificare l'orrore l'articolo vero e proprio mi ha fatto pensare anche a questo.

In genere, nelle classi di grandi dimensioni inserirò una regione attorno alle variabili, alle costanti e alle proprietà dei membri per ridurre la quantità di testo che devo scorrere e lasciare tutto il resto al di fuori di una regione.Sui moduli generalmente raggrupperò le cose in "variabili membro, costanti e proprietà", funzioni del modulo e gestori di eventi.Ancora una volta, questo è più utile per non dover scorrere molto testo quando voglio solo rivedere alcuni gestori di eventi.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow