Senza tempo per il refactoring, quando stai lavorando su un codice legacy, con le convenzioni più terribili, qual è la migliore pratica?
Il tentativo di seguire lo stile di codifica migliore migliorerebbe la leggibilità o addirittura lo danneggerebbe?
Ad esempio, i nomi dei metodi java sono in genere camel cased:
myGoodNamedMethod
Ma nel repository ci sono codice con metodi come questo (non tutti, ma la maggioranza)
my_c_style_method_that_looks_off_in_java
Per quanto strano trovi le convenzioni esistenti, SEGUIRLI. Avere alcune convenzioni, anche se non ti piacciono, è FAR molto meglio di non averne.
Ovviamente non è sempre vero (alcune convenzioni sono apertamente ostili al lavoro finito, come limitare tutti i nomi a 8 caratteri senza una buona ragione), ma tranne nei casi più estremi, basta seguire cosa c'è.
Segui lo standard esistente.
Tuttavia, se c'è un reale bisogno di risolverlo (sta diventando un problema grave), fare un respiro profondo, man up e refactoring l'intero codice base per seguire un nuovo standard. Ma fallo solo se è veramente necessario, hai l'approvazione di tutti e se ne hai il tempo. Probabilmente non ci vorrà tutto il tempo che potresti pensare, ma fai prima la tua ricerca.
Segui gli standard esistenti. Forse sono obsoleti / dispari / sbagliati / spiacevoli. (a patto che non siano ostili come @Michael Kohne menzionato).
Potrebbero esserci motivi al di fuori degli standard linguistici per utilizzare lo stile di denominazione. Ho sentito di persone che eseguono applicazioni di terze parti sulla base del codice per estrarre i nomi da utilizzare in seguito. Ad esempio, i nomi dei test come requisiti o la documentazione di auto building api.
Leggi altre domande sui tag coding-style coding-standards