Equivalente a "Principio di minimo stupore" per lo stile del codice?

Sii coerente.

Ogni giorno esegui qualche atto di gentilezza casuale sul codice.

Sì, fallo entrambe.

Il codice si decompone se non viene mai aggiornato. Questa è una metafora. Sicuramente la fonte intatta funziona altrettanto bene che mai. Guarda la fonte intatta degli anni '60 da qualche tempo. L'intero punto del codice sorgente piuttosto che il codice macchina è che possiamo leggerlo e cambiarlo. Anche se il codice potrebbe non cambiare, lo faremo sicuramente.

Ho lavorato su un codice che rifletteva la migliore saggezza assoluta al momento in cui è stato scritto, da quattro diversi decenni nella stessa base di codice. Stupore non inizia a coprirlo.

C'è così tanto che puoi aggiustare. Solo così tanto che puoi trascinare con te nel futuro. Devi scegliere le tue battaglie. Ma quando nuove persone arrivano a un progetto e tu le osservi faticare a mettere le loro teste in vecchi modi di pensare, alcuni candidati per un serio aggiornamento dovrebbero venire di volta in volta.

A parte ciò, la cosa migliore che puoi fare è chiarire dove si trovano le linee. Se il sistema contabile è famoso per essere OOP e il sistema di provisioning è famoso per essere funzionale, lascia che abbiano i loro capricci. Almeno quando mi siedo con uno di loro so cosa aspettarmi.

Se il sistema di auditing è famoso per avere uno stile completamente imprevedibile, è tempo di lanciare una moneta e dargli una personalità prevedibile. Mi piace quando il mio caos viene chiaramente etichettato.

Inizia con il documento sugli standard di codifica. Basare quello sullo stile usato dalla lingua stessa . In questo modo i neoassunti in arrivo dovrebbero essere in grado di comprendere rapidamente il codice - che di per sé è il PoLA che stai cercando. In Delphi (il predecessore spirituale di C #) c'era un "stile Borland" molto preciso in cui era scritto il codice sorgente di Delfi e non era saggio deviare (anche se ho incontrato un certo numero di devianti :). Dovresti avere meno resistenza usando lo stile di Microsoft in-house di "il modo funky di Fred con i commenti e le parentesi graffe" anche se probabilmente avrai ancora un po 'di resistenza.

Un secondo suggerimento oltre a correggere in modo iterativo la formattazione mentre apporti le modifiche a ciascun file consiste nell'individuare i formattatori di codice automatici (potresti avviare qui ) e usarli per riformattare il codice di ogni applicazione in modo che corrisponda agli standard di codifica una volta che sono stati finalizzati. In questo modo, tutti sono sulla stessa pagina e il codice è tutto coerente.

Una cosa da tenere d'occhio; Una volta ho lavorato in un luogo che implementava un formattatore di codice automatico sul check-in del loro sistema di controllo della versione per applicare la coerenza, che non è una cattiva idea. Ciò che è stato discutibile è stato quando un paio di "Freds" di cui sopra hanno scritto un set di regole di formattazione personalizzate per le loro funky deviant preferenze e le hanno applicate al loro check-out dal sistema di controllo delle versioni in modo da poter continuare a codificare nello stesso stile incompatibile con cui stavano bene . Potresti desiderare di scoraggiarlo.

Sì, hai l'idea giusta.

Se hai un sottosistema che segue coerentemente diverse convenzioni dello stile di codifica generale, allora il nuovo codice all'interno del sottosistema dovrebbe preferibilmente seguire le convenzioni stabilite in questo sottosistema.

Se si desidera modificare il sottosistema per conformarsi a una nuova convenzione, è preferibile farlo in un colpo solo, o se ciò non è possibile, farlo un intero componente alla volta. Avere diverse convenzioni attive allo stesso tempo nello stesso codice è un casino.

Ad esempio: dì che segui le linee guida per i nomi C #, ma hai un sottosistema che, per ragioni storiche, segue lo stile di denominazione Java (metodi del caso cammello e così via). Le convenzioni di denominazione sono comunque utili se si conosce quale stile è attivo. Ma se inizi a mescolare gli stili nello stesso codice, all'improvviso hai qualcosa che è molto meno comprensibile di uno qualsiasi degli stili, non molto meglio che non avere affatto uno stile.