Penso che dipenda da quanto grande sarà il progetto complessivo.
Ad un estremo, diciamo che hai un progetto 1 Mloc. Per quel grande progetto, è improbabile che un singolo individuo sia un "esperto" in tutte le aree coinvolte. Quindi in questo caso, vorrei attenermi agli stili di codice esistenti per ciascun componente principale. I nuovi sviluppatori sceglieranno un'area, lo apprenderanno ed è improbabile che vedano molti altri componenti che potrebbero avere stili di codice diversi.
Se il progetto è molto più piccolo, dove è è probabile che le persone capiscano l'intera base di codice, allora sceglierei uno stile di codice dominante e lo seguirò. In questo caso, ritengo che la coerenza nell'intero progetto abbia più senso perché i nuovi sviluppatori probabilmente lavoreranno in tutte le aree del progetto.
I progetti di medie dimensioni sono forse i più difficili da prendere per questa decisione. In questo caso, devi valutare i costi per ciascun approccio e decidere quello che pensi sia il meno costoso a lungo termine. La sfida è che i progetti di medie dimensioni sono solitamente cresciuti appena quanto basta per un refactoring di stile completo che sembra proibitivo. Potresti voler dare una seconda occhiata alla struttura ad albero del codice per vedere se è possibile organizzare le cose per raggruppare particolari stili di codice.
In entrambi i casi, la decisione finale dovrebbe riposare con il team che stai mettendo insieme questo pacchetto.
Alcuni dei valori anomali che potrebbero spostare il mio ragionamento dall'alto:
-
Se uno o più moduli hanno uno stile atroce, allora non ha senso mantenerlo, anche su un progetto più ampio. Sì, lo stile è soggettivo, ma se a te e ai tuoi colleghi partecipanti al progetto non piace molto il modo in cui le aree particolari fluiscono, nuke il vecchio stile e ne dà uno migliore.
-
Se tutti gli stili sono ragionevolmente vicini l'uno all'altro, potrebbe essere altrettanto semplice dichiarare "ecco il nuovo modo" e usarlo per tutto il nuovo codice e i significativi refactoring. Questo può rendere le recensioni un po 'dolorose, ma nella mia esperienza la maggior parte delle persone è abbastanza capace di adattarsi a questo approccio. Fornisce inoltre un segnale rivelatore in cui è presente il vecchio codice.
-
A volte lo stile viene spostato in base alla nuova funzionalità aggiunta alla lingua. C ++ ha acquisito una serie di funzionalità nel corso degli anni. Potrebbe essere opportuno rifattorizzare, se necessario, lo stile precedente in uno stile più recente che sfrutta tali caratteristiche.
-
Alcune librerie possono avere un approccio o uno stile particolarmente idiomatico. Se è così, rimango con quello stile per quella libreria anche se potrebbe essere in conflitto con il resto del progetto. L'intento qui è di aumentare le probabilità che qualcuno che lavora su frobnosticators su altri progetti funzionerà anche sul tuo progetto.
Alcuni dei commenti hanno menzionato gli stili imperativo e orientato agli oggetti come una considerazione.
I moduli che sono "pesanti" in uno stile particolare dovrebbero probabilmente rimanere tali se il modulo è di medie o grandi dimensioni. Ho lavorato con i tre stili principali (imperativo, oggettivo e funzionale) e ho rifatto lo stile imperativo pesante in uno stile OO. Con una quantità di codice media o maggiore, il refactoring può essere (eccezionalmente) difficile. La mia esperienza è stata confusa perché non avevo alcun supporto per gli strumenti per aiutare nel refactoring.
Immaginerei che ci sia un'alta correlazione tra i moduli dallo stile strongmente imperativo e quei moduli che sono idiomatici per particolari nicchie di sviluppo, che risalgono all'ultimo punto che ho sollevato con valori anomali. Quindi, il modulo qualsiasi che troverete per quella funzionalità sarà simile a quello, e vorrete che gli esperti di quel dominio possano facilmente lavorare anche sul vostro progetto. Ma se ci sono opzioni e il tuo team non apprezza lo stile di quel modulo, allora vorrei studiare le opzioni.
Allo stesso modo, ho lavorato con un modulo in stile OO pesante in cui i principi OO sono stati presi troppo in là e utilizzati in modo errato. Ad esempio, le interfacce venivano utilizzate come sostituto dell'ereditarietà multipla. E come ci si potrebbe aspettare, è stata un'implementazione cruda. Sono stato in grado di compiere progressi ragionevoli nel refactoring di quel modulo, ma alla fine ho abbandonato questo approccio in quanto ho trovato invece dei pacchetti migliori da usare.