Vantaggi e svantaggi della riforma del codice forzato

Attualmente sto lavorando in un posto che potrebbe cercare di costringere gli sviluppatori a utilizzare un formattatore di codice automatizzato al momento del check-in di controllo della versione. Sto cercando opinioni degli sviluppatori sui vantaggi e gli svantaggi di farlo ... come pensi che possa aiutare o ostacolare gli sviluppatori. Il mio caso specifico riguarda Java / JSP, ma penso che la domanda potrebbe applicarsi a qualsiasi lingua.

Penso che sia molto importante farlo. Ecco perché:

• Fa in modo che i diff del controllo del codice sorgente mostrino solo le effettive modifiche al codice e elimina quasi del tutto il "rumore diff" dovuto agli spazi bianchi e ad altre insignificanti scelte di formattazione
• Rende tutto il codice più simile, in modo che gli sviluppatori siano più a loro agio nell'associare e condividere le basi di codice

Se lo fai, consiglierei a tutti di archiviare tutto il codice, quindi una persona esegue una riformattazione sull'intera base di codice, quindi controlla di nuovo tutto in modo che ci sia un "gigantesco" set di modifiche per la formattazione (che tutti possono ignorare), ma dopo ciò, tutte le differenze sono differenze di codice reali.

Se lo fai a poco a poco, mescolerai le modifiche del codice reale con le modifiche di formattazione e le cose diventeranno inutilmente disordinate nella terra del cambiamento.

Lancio qui la mia risposta poiché le persone sembrano solo aggiungere vantaggi. Quello che vedo come svantaggi sono:

• Elimina la capacità di fare "meglio" del formatter automatico ... annullerà la tua formattazione più pulita. Un esempio di questo potrebbe essere dichiarazioni di parametri basate su colonne, elenchi di aggiunte discrete di oggetti, ecc.
• Crea una resistenza al cambiamento delle convenzioni di stile in quanto queste ora creeranno grandi cambiamenti fuorvianti.
• Rimuove la possibilità di eseguire qualsiasi formattazione di "casi speciali" in cui un formato alternativo renderebbe il codice più leggibile.
• Ti lega all'uso di IDE che supportano esattamente le funzionalità di riformattazione di cui hai bisogno. In un altro IDE manca una delle opzioni di cui hai bisogno, causerà almeno alcuni problemi.
• Diventa problematico condividere un repository di codice scrivibile con un gruppo esterno a meno che non utilizzino esattamente le stesse convenzioni di formato del tuo gruppo (di solito lo faranno, ma non sempre).
• Ci saranno sempre delle eccezioni in cui un formato leggermente diverso è probabilmente più pulito dello stile prescritto. La conversione automatica può quindi spesso nascondere l'intento di alcuni blocchi di codice, il che è efficace quanto aggiungere un difetto al codice.

In poche parole, un insieme di convenzioni non automatizzate stabilisce requisiti minimi di stile / leggibilità, in cui le convenzioni automatizzate fissano un minimo e un massimo.

Ricordo di aver guardato VB (forse la versione 5) e di aver trovato una delle cose più fastidiose al riguardo era che avrebbe riformattato forzatamente il mio codice e rimosso le cose sopra e oltre la sua formattazione di base.

Trovo che la formattazione forzata del codice sia ottima. Consente a uno sviluppatore di attraversare l'intero corpus di codice senza far rimbalzare gli occhi dappertutto. Anche avere questo standard in atto aiuta gli sviluppatori alle prime armi a rompere le cattive abitudini.

Lo svantaggio principale è perdere la formattazione personalizzata laddove conta davvero.

Immagina un tipico controllo di sanità mentale se () non riuscirà se una delle condizioni specifiche è presente ma non soddisfatta ...

  if(
      (user.id == TEST_ID)
    ||(
         (user.id == UserID)
       &&( 
             ( user.type == HUMAN_USER && user.name.size() >= MIN_NAME )
           ||( user.type == EMULATION && input.source != SOURCE_INTERNAL ))
       && ( user.email == NULL || emailValidator.isValid(user.email))
       && ( (user.phone == NULL) == (user.type == EMULATION) )

       // several more lines like this.)
    ){ /* handle results */ }

Ciò è leggibile grazie al rientro ragionevole che segue la struttura logica delle condizioni.

Ora il tuo strumento automatizzato non ha idea della separazione logica di condizioni diverse in linee correlate. Non vede alcun motivo per cui ogni gruppo 3-4 condizioni in una riga e dividere la condizione successiva a metà. Oppure lo dividerà, un'espressione di confronto per riga. Può anche sembrare più bello sullo schermo ma la logica andrà persa.

Ho aggiunto una risposta con svantaggi e aggiungerò anche quello che considero un grande vantaggio.

Quando si utilizza un codice automatico riformattato su commit, si apre effettivamente la possibilità di variazioni delle preferenze personali senza il solito effetto di avere le proprie preferenze inflitte ad altri. Puoi avere il tuo codice formato IDE su uno standard comune su commit, ma visualizzalo nel tuo formato preferito senza influire sugli altri.

Questo per me è quasi il Santo Graal della codifica basata su convenzioni ... ottieni i vantaggi di un formato di codice comune, ma permetti comunque di supportare le preferenze personali senza conflitti.

Dipende dalle tue esigenze, ma alcune controindicazioni sono abbastanza utili, ad esempio ogni if ​​() dovrebbe essere seguito da parentesi graffe, poiché è abbastanza facile ottenere un tale se sbagliato se stai refactoring.

Considera quel caso:

if( x == 0 ) 
   return foo;
//do something else
return bar;

Se ora vuoi aggiungere un po 'di registrazione al caso if potresti accidentalmente scrivere:

if( x == 0 ) 
  log.info("x was 0");
  return foo;
//do something else
return bar;

E di conseguenza il tuo metodo ritorna sempre foo.

Modifica: non si tratta della formattazione automatica ma piuttosto del controllo dello stile. Scusate se anche quella risposta era fuori tema. :)

Aiuta notevolmente a uniformare il codice nell'azienda e grazie a ciò generalmente produci una struttura più facilmente comprensibile e molto più facilmente gestibile per il tuo prodotto.

Bene, i vantaggi sono gli stessi di qualsiasi formattatore di codice, come standardizzazione del codice, semantica tra sviluppatori, ecc. L'unico possibile svantaggio che vedo è la mancanza di un occhio umano dopo la formattazione, per aggiungere alcune eccezioni, ecc.
Quindi Immagino sia meglio considerare un formattatore IDE invece di un formattatore del tempo di check-in.

Nella mia esperienza, è una buona cosa. Senza uno, i confronti di codice mostrano spesso un pasticcio di formattazione degli spazi bianchi e possono nascondere le effettive modifiche al codice. Nella mia esperienza, fare casini con la formattazione di qualcuno non è il peccato che si è scoperto essere, specialmente con i potenziali benefici della coerenza in tutto il team.