Vantaggi e svantaggi del riformattato codice forzato

Penso che sia molto importante farlo. Ecco perché:

• Fa in modo che le differenze di controllo sorgente mostrino solo modifiche effettive del codice, e tutto, ma elimina il "rumore diff" a causa di spazi bianchi e altre scelte di formattazione insignificanti
• Rende tutto il codice più simile, in modo che gli sviluppatori siano più comodi nell'accoppiamento e nella condivisione delle basi di codice

Se lo fai, consiglierei a tutti di controllare tutto il codice, quindi una persona fa un riformattare sull'intero codice base, quindi controlla tutto di nuovo in modo che ci sia un set di modifiche "giganti" per la formattazione (che tutti possono ignorare ), ma dopo di ciò, tutte le diff sono le differenze del codice reale.

Se lo fai a poco a poco, mescolerai le reali modifiche al codice con le modifiche di formattazione e le cose si metteranno inutilmente in disordine nel cambio di terreno.

Qui lancio la mia risposta in quanto le persone sembrano solo aggiungere vantaggi. Quello che vedo come svantaggi sono:

• Elimina la capacità di fare "meglio" del formattatore automatico ... annullerà la formattazione più pulita. Un esempio di questo sarebbe dichiarazioni di parametri basate su colonne, elenchi di aggiunte discrete di oggetti, ecc.
• Crea una resistenza al cambiamento delle convenzioni di stile in quanto ora creeranno grandi cambiamenti diff diffidenti.
• Rimuove la possibilità di eseguire qualsiasi formattazione 'caso speciale' in cui un formato alternativo renderebbe il codice più leggibile.
• Ti lega agli 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 utilizzi esattamente le convenzioni di formato del tuo gruppo (di solito lo fanno, ma non sempre).
• Ci sono sempre delle eccezioni in cui un formato leggermente diverso è probabilmente più pulito dello stile prescritto. La conversione automatica può quindi nascondere l'intento di determinati blocchi di codice, che è efficace proprio come aggiungere un difetto al codice.

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

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

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

Lo svantaggio principale sta perdendo la formattazione personalizzata dove è davvero importante.

Immagina un tipico controllo di integrità se () fallirà 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 */ }

Questo è leggibile grazie a un indenting ragionevole che segue la struttura logica delle condizioni.

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

Ho aggiunto una risposta con degli svantaggi e inserirò quello che considero un grande vantaggio.

Quando si utilizza un reformat di codice automatizzato sul commit, in realtà si apre la possibilità di variazioni delle preferenze personali senza il consueto effetto di avere le proprie preferenze inflitte agli altri. Puoi avere il tuo codice di formato IDE su uno standard comune in fase di commit, ma visualizzarlo nel formato preferito senza influire sugli altri.

Questo per me è quasi il Santo Graal della convenzione basata sulla convenzione ... ottieni i vantaggi di un formato di codice comune, ma permetti comunque che le preferenze personali vengano supportate senza conflitti.

Dipende dai tuoi bisogni ma alcuni contrappesi sono abbastanza utili, ad es. ogni if () dovrebbe essere seguito da parentesi graffe, dal momento che è abbastanza facile ottenerlo se è sbagliato se si esegue il refactoring.

Considera questo caso:

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

Se ora vuoi aggiungere qualche registrazione al caso if potresti scrivere accidentalmente:

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

E inaspettatamente il tuo metodo restituisce sempre foo .

Modifica: non è sulla formattazione automatica ma piuttosto sul controllo dello stile. Scusa se quella risposta era fuori tema pure. :)

Aiuta enormemente ad uniformare il codice all'interno dell'azienda e, grazie a questo, generalmente produci una struttura più facilmente comprensibile e più facilmente manutenibile per il tuo prodotto.

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

Nella mia esperienza, è una buona cosa. Senza uno, i confronti del codice spesso mostrano un pasticcio di formattazione degli spazi bianchi e potrebbero nascondere le effettive modifiche al codice. Nella mia esperienza, scherzare con la formattazione di qualcuno non è il peccato che si è creato, specialmente con i potenziali benefici della coerenza all'interno del team.