Dovremmo inserire classi, enumerazioni e altre entità nei propri file?

Question

Ho avuto una discussione con la nostra azienda teamlead \ architect su questo argomento.

Sostiene che è più facile capire il progetto su grande scala se "entità collegate dalla logica" sono collocate in un file cs.

cito:

1. "Tutta la struttura della logica e l'interfaccia e la classe può essere visto in un posto, questo è un argomento che non può essere confutare Per vedere lo stesso. cosa ma con un sacco di file è necessario utilizzare gli strumenti, il diagramma di classe, R # per la navigazione, ecc. "

2. "Dopo il povero teoria potrei urlare che un esercito di file separati è fresco, ma quando si tratta di apportare modifiche al codice esistente, soprattutto se non fossi uno scrittore di questo codice, è molto difficile per capire un sacco di file sparsi. Così il forum, è possibile scrivere che "un enum- un unico file", ma in pratica questo approccio non dovrebbe mai essere usato "

3. " ... per quanto riguarda la separazione del codice di base tra gli sviluppatori, al giorno d'oggi non è un problema modificare contemporaneamente lo stesso file. L'unione non è un problema. "

ho sentito e letto molte volte che dobbiamo creare una cs-file per enum, di classe e così via, e questo è la migliore pratica.

Ma non riesco a convincerlo. Dice che non si fida di programmatori noti come Jon Skeet. A proposito, ecco l'opinione di Skeet su questo argomento Where is the best place to locate enum types?

Cosa ne pensi? C'è un problema reale? O è una questione di gusti e dovrebbe essere regolata dallo standard di codifica dell'organizzazione?

Answer 1

A mio parere:

Piccole enumerazioni e le classi che sono necessarie all'interno di una classe logica più grande possono soggiornare nel suo file.
Ma se le classi più piccole e le enumerazioni vengono utilizzate al di fuori di tale ambito, le si dovrebbe avere separatamente (anche se sono collegate logicamente esse stesse potrebbero essere nello stesso file).
Quindi sono d'accordo con lui sull'accoppiamento logico.

Detto questo, devo dire che ci sono altre alternative, è possibile creare cartelle logiche all'interno di un progetto per mantenere le classi dallo stesso ambiente logico o connessioni.
Gli IDE offrono oggi un facile accesso e mobilità per tutta la soluzione con la funzionalità Go-To, quindi trovare il codice non è un problema.

Mantenere insieme i componenti logici (purché siano strettamente accoppiati) ha un grande vantaggio durante il ridimensionamento. Man mano che il progetto si ingrandisce, tende ad avere più confusione, ed è esattamente ciò che sta cercando di evitare.

BTW, se si legge l'opinione di Skeet attentamente si noterà:

e supponendo che stanno andando per essere utilizzati da altre classi, rendere i tipi di loro alto livello nelle proprie file.

Answer 2

Penso che il tuo parere "teamlead \ architect" sia in gran parte basato su usanze scadenti di spazi dei nomi. ogni volta che ho sentito questo argomento da uno sviluppatore è a causa della quasi totale mancanza di utilizzo dello spazio dei nomi (e poi diventa davvero caotico se aggiungi molti file)

Answer 3

Questa è una questione di opinione, e quindi sarebbe meglio postato qui:

https://codereview.stackexchange.com/

Tuttavia, di solito è necessario posizionare tutte le definizioni di tipi nelle proprie file, con alcune eccezioni:

• una classe contratti di codice utilizzato per fornire contratti per unla classe base astratta o l'interfaccia appartengono logicamente a quella classe.

• Un enum che è solo utilizzato come parametro, proprietà o valore restituito all'interno di una classe appartiene anche a tale classe (ma non è annidato al suo interno).

Ci sono probabilmente alcune altre eccezioni, ma in generale ogni tipo dovrebbe andare in un file separato.

Answer 4

Non sono d'accordo con molti punti del "teamlead/architetto" qui.

Come un sacco di cose da fare con il codice, è una questione di opinione.

Personalmente, credo che sia meglio creare un file .cs per enum, classe e così via. Di solito se c'è una classe che è più strettamente associata all'enum, e li metto nello stesso file.

Accetto che le aziende possano disporre di un proprio standard di codifica, ma quello suggerito qui è semplicemente sbagliato in quanto va contro molto di ciò che considererei una buona pratica.

Answer 5

Tu e lui puoi dare un'occhiata a un gran numero di complessi progetti open source su Internet. Guarda github, codeplex e luoghi simili.

Ad esempio, guardare il codice sorgente MVC. Se la classe per file è abbastanza buona per Microsoft e un progetto complesso come MVC, penso che ci siano buone probabilità che sia anche abbastanza buono per voi ragazzi.

Personalmente uso la classe/interfaccia per approccio di file (tranne in casi particolari, come avere un piccolo enume, ma quello soggettivo) e non vedo alcun problema con esso.

Answer 6

Interessante domanda, questa è la mia opinione.

È necessario fare una distinzione tra il raggruppamento logico (spazio dei nomi) e il raggruppamento fisico (file/progetto).

In ogni caso, un'enumerazione deve essere inserita nello spazio dei nomi logico a cui appartiene business business, non in uno spazio dei nomi che contiene solo enumerazioni o non specifica nemmeno l'enumerazione nel nome dello spazio dei nomi. Non ha senso avere uno spazio dei nomi di 'Enum', poiché in tal caso si avranno concetti ingombranti e non si specifica il dominio a cui appartiene.

Se un'enumerazione viene utilizzata da un solo tipo di classe, è anche possibile inserirla nella classe stessa. In questo modo, è chiaro che appartiene a quella particolare classe e come tale si trova nello stesso file di codice. Se l'enumerazione è più simile a un enum general purpose, utilizzato in più classi, quindi metterlo separato nel proprio file di codice.

Quindi non sono d'accordo con il comando della squadra: se lo metti nello stesso file, rendilo parte della classe stessa perché è quello che stai effettivamente dicendo se lo inserisci nello stesso file, altrimenti lo metti nel suo stesso file di codice. Penso che sia comunque un uso più coerente.