È una buona idea imporre lo stesso formato di codice per tutti gli sviluppatori?

Stiamo pensando di imporre un unico formato di codice standard nel nostro progetto (formato automatico con azioni di salvataggio in Eclipse). Il motivo è che attualmente c'è una grande differenza nei formati di codice utilizzati da diversi (> 10) sviluppatori, il che rende più difficile per uno sviluppatore lavorare sul codice di un altro sviluppatore. Lo stesso file Java a volte utilizza 3 formati diversi.

Quindi credo che il vantaggio sia chiaro (leggibilità => produttività) ma sarebbe una buona idea imporlo? E se no, perché?

AGGIORNAMENTO
Tutti usiamo Eclipse e tutti sono a conoscenza del piano. Esiste già un formato di codice usato dalla maggior parte, ma non viene applicato poiché alcuni preferiscono attenersi al proprio formato di codice. A causa delle ragioni di cui sopra alcuni preferirebbero applicarlo.

Attualmente lavoro in un luogo in cui viene applicato un formato di codice standard e il codice viene formattato automaticamente durante il salvataggio del file, proprio come stai per fare. Come nuovo membro della società ho scoperto che le regole comuni di formattazione mi davano la sensazione calda e confusa che "questi ragazzi sanno cosa stanno facendo", quindi non potrei essere più felice. ;) Come nota a margine correlata, con le regole di formattazione comuni applichiamo anche alcune impostazioni di avviso del compilatore piuttosto rigide in Eclipse, con la maggior parte impostate su Errore, molte su Avviso e quasi nessuna su Ignora.

Direi che ci sono due ragioni principali per imporre un unico formato di codice in un progetto. In primo luogo ha a che fare con il controllo della versione: con chiunque formatta il codice in modo identico, tutte le modifiche ai file sono garantite per essere significative. Non basta più aggiungere o rimuovere uno spazio qua o là, figuriamoci riformattare un intero file come "effetto collaterale" di cambiare effettivamente solo una riga o due.

La seconda ragione è che in un certo senso elimina dall'ego l'ego dei programmatori. Con tutti formattando il loro codice allo stesso modo, non puoi più facilmente dire chi ha scritto cosa. Il codice diventa proprietà più anonima e comune, quindi nessuno deve sentirsi a disagio nel cambiare il codice di "qualcun altro".

Essendo questi i motivi principali, ce ne sono anche altri. Trovo confortante il fatto che non devo preoccuparmi di pensare alla formattazione del codice, poiché Eclipse lo farà automaticamente per me quando salverò. È spensierato, come scrivere documenti con LaTeX: è formattato in seguito e non devi preoccuparti durante la scrittura. Ho anche lavorato in progetti in cui ognuno ha avuto il proprio stile. Quindi devi pensare a problemi stupidi e insignificanti come se è OK modificare il codice di qualcun altro nel tuo stile o se invece dovresti provare a imitare il loro stile.

L'unico argomento contro le impostazioni comuni di formattazione del codice che mi viene in mente per il tuo caso è che apparentemente è un progetto già in corso, quindi causerà molte modifiche inutili in tutti i file, rovinando le storie dei file effettivi. Lo scenario migliore è se puoi iniziare a far rispettare le impostazioni fin dall'inizio di un progetto.

Ogni sviluppatore di software professionale preferirà adottare uno standard (buono) piuttosto che entrare in guerre evangeliche rispetto allo stile, proprio per le ragioni che hai delineato.

Molti sviluppatori di software conducono guerre evangeliche ......

A seconda della posizione all'interno della squadra e delle dinamiche della squadra, puoi decidere che non è possibile vincere la guerra. In questo caso, potrebbe essere meglio non iniziare ...

Sì, è bene avere uno stile di formato di codice per tutti gli sviluppatori.

Progetta i formati di stile del codice e importali in tutti gli sviluppatori eclissi.

Ciò sarà di aiuto quando passiamo mergingal sistema "Controllo versione".

Che cosa stai cercando di ottenere, quanto sarà importante la ritenzione anale nel metterlo in atto (e nel livello di dettaglio che verranno definite le tue "regole"), proverai a far rispettare il codice scritto in diverse lingue, proverai ad applicarlo retroattivamente sul codice esistente?

1. un aspetto comune al codice può davvero aiutare a renderlo più leggibile, ma può anche peggiorare le cose se è l'aspetto e l'aspetto sbagliato. La notazione _hUngarian_lpfstr è un ottimo esempio :)
2. Ho visto "standard di codice" che impongono il numero di spazi degli spazi bianchi tra i blocchi di commenti, l'ordinamento alfabetico dei nomi dei metodi e altre sciocchezze. Non farlo.
3. Lingue diverse hanno standard diversi a cui le persone sono abituate nel loro uso. Alcuni addirittura impongono questi standard (pensa che Python, Cobol, Visual Studio impongano automaticamente convenzioni di rinforzo in stile C ++ mentre Java usa lo stile C per convenzione, ecc. Ecc.).
4. non cambiare mai il codice esistente per modificarlo, stai solo introducendo nuovi problemi in quel modo. Ciò significa sezioni di codice e interi file di origine. Quindi non andare in giro a riformattare il codice esistente quando qualcuno cambia una singola riga in un file di 1000 righe.
5. i programmatori esperti possono essere molto più produttivi se non devono pensare per metà del tempo se ciò che stanno scrivendo "sembrerà giusto" al sistema di approvazione automatico o al revisore. Avranno anche l'abitudine di scrivere codice pulito semplicemente perché è quello che funziona, anche se ci sono piccole differenze tra i loro stili naturali.

Quindi, mentre ci sono buoni motivi per imporre uno stile e uno standard specifici, ci sono anche buoni motivi per non farlo (troppo) rigorosamente.

Sì, la coerenza è una buona idea, per ragioni che altri hanno menzionato .

Volevo solo aggiungere un paio di punti che non sono stati usati altrove:

• Oracle ha pubblicato una serie di convenzioni per Java, che sono di fatto lo standard.
  • L'uso di questi dovrebbe aiutarti a evitare argomenti su quale stile seguire.
  • Molte biblioteche pubbliche e progetti open source tendono ad usare queste convenzioni, quindi quando è necessario esaminare quelle la formattazione dovrebbe essere familiare.
  • Il formatter di Eclipse ha regole integrate per abbinare queste convenzioni, il che dovrebbe anche aiutare.
• È possibile prendere in considerazione la possibilità di creare un hook nella configurazione del controllo del codice sorgente in modo che il codice venga formattato automaticamente prima di entrare nel ramo principale.
  • Puoi evitare battaglie con programmatori particolarmente testardi che si rifiutano di seguire lo standard. Possono anche usare la propria formattazione mentre lavorano, che verranno standardizzati in seguito!
  • Se finisci per utilizzare le impostazioni di formattazione personalizzate (ad esempio, molte persone ignorano la convenzione "max 80 caratteri per riga") devi solo apportare modifiche in un unico posto.

Facevo parte di un team che utilizzava il plug-in Checkstyle . Invece di utilizzare le funzionalità predefinite, abbiamo formato un piccolo comitato di sviluppatori interessati. Discutemmo di ciò che sembrava mancare, di ciò che sembrava eccessivo e di martellare le cose. Tutti abbiamo imparato qualcosa nel processo e rafforzato quei muscoli degli sviluppatori.

(Esempi delle nostre decisioni: 72 caratteri di larghezza sono troppo piccoli, ma 120 era meglio; è meglio usare _ALLCAPS per finali statiche; applicare una singola uscita da una funzione è una buona idea.)

Quando abbiamo avuto le revisioni del codice, una delle prime domande era: "L'hai eseguito tramite Checkstyle?" Il rispetto degli standard di codifica è stato in gran parte automatizzato e ha distolto l'attenzione dal revisore che è esigente. È stato meravigliosamente facile avere Checkstyle evidenziare una firma del metodo, fare clic con il tasto destro e cambiare una variabile in final. Potrebbe anche correggere i rientri e le parentesi graffe in modo che il codice di tutti avesse un aspetto simile. Manca un Javadoc per una funzione pubblica? Checkstyle indicherà la funzione.

(La rimozione dell'odore di codice è più importante della formattazione coerente. Questo è un vantaggio degli strumenti automatizzati.)

Posizionerei strumenti automatizzati come Checkstyle meno come imporre lo stesso formato e più per incoraggiare un aspetto simile. E quando stai allevando i gatti, uno strumento automatizzato può aiutare ad affinare le abilità e ridurre l'odore del codice senza lividi ego fragili.

Se ti atterrai allo stesso IDE e incorporerai alcuni strumenti di formattazione, è una buona idea perché non hai bisogno di troppi sforzi. Mantieni le regole semplici concentrandoti sulla leggibilità e non sulla ritenzione anale . Questo dovrebbe essere il metro.

Sebbene una palla di fango costantemente formata sia migliore di una semplice palla di fango, il tuo tempo sarebbe meglio passare a pulirlo invece di diventare troppo esigente su dove vanno le parentesi. Non diventare il manager con la spilla che sente di fare il proprio lavoro contando gli spazi di rientro durante una revisione del codice e assicurandosi che le nuove copertine siano presenti nei Rapporti TPS .

Le preferenze personali sono proprio questo e raramente migliorano la produzione: https://stackoverflow.com/questions/249432/whats-the-reasoning-behind-the-different-brace-forms

Se lo fa, superalo e fai qualcosa.

Consiglio vivamente che gli esseri umani impongano la formattazione del codice e che le lievi infrazioni siano gentilmente trascurate o ritoccate. Le ragioni sono brevemente

1. La macchina sbaglia nel peggior momento possibile e di solito quando si utilizza una nuova funzione di lingua. Come gestirà le chiusure in Java, ecc.? Jalopy ha problemi con gli enum con le funzioni membro.
2. Penso che sia un onere molto ragionevole imporre al programmatore di produrre codice per l'azienda che assomigli a un codice aziendale. Ho trovato utile menzionare che questo è il modo in cui il codice viene formattato "qui", non come tutto il codice dovrebbe essere formattato ovunque. La loro compagnia precedente potrebbe aver scelto un percorso diverso, e va bene. Non diversamente dal linguaggio vernacolare, ci sono modi di dire specifici per la tua cultura del codice che vuoi mettere in evidenza.
3. L'applicazione della sintassi del codice viene eseguita meglio con le revisioni del codice:
   1. Se la formattazione è importante, è necessario che la tua organizzazione esegua revisioni del codice. Questo è di enorme beneficio.
   2. Se una regola di formattazione viene infranta, un essere umano può guardarla e giudicare meglio di una macchina se l'intento viene trasmesso in modo più pulito. Questo è molto raro, ma succede occasionalmente.

Per quanto riguarda "leggibilità => produttività", la struttura del codice (come le classi e le funzioni a responsabilità singola) ti acquisterà molto più velocemente della formattazione del codice. La formattazione del codice può essere di aiuto, ma menti diverse analizzano le dichiarazioni in modo diverso: non tutti saranno "più produttivi". Vorrei raddoppiare la struttura del codice rispetto alla formattazione perché è qualcosa che ti spinge anche a fare revisioni del codice e indurre il team a pensare a come funziona il programma, non all'aspetto di un singolo ciclo.

Non sono un grande fan di Domain Driven Design, ma è un modello recente che ha un'idea MOLTO ben definita su come il codice dovrebbe essere strutturato e le convenzioni di formattazione del codice fluiscono naturalmente da un programma strutturato di Domain Driven Design. Ancora una volta ... Non mi piace DDD, ma è un ottimo esempio perché è così ben definito.

Suppongo che il tema di questa risposta sia: Esegui revisioni del codice e consenti alla formattazione di fluire dalla cultura e dal processo di revisione.

In generale, supponendo che si assumano sviluppatori ragionevoli, è una cattiva idea imporre un formato di codice universale. È comunque una buona idea adottare linee guida per il codice .

Non ho mai visto un insieme di regole di formattazione del codice che ottimizzi la leggibilità in tutti i casi. Allo stesso modo non ci sono regole grammaticali applicabili al 100% in inglese: i nostri cervelli non sono collegati in questo modo. Quindi usa le linee guida, ma dai agli sviluppatori la libertà di sovrascriverle quando lo ritengono opportuno.

Detto questo, una regola più dura di "seguire la convenzione di codice che esiste già nel file / progetto" è una buona regola.

Ma tieni presente che la formattazione contribuisce molto meno alla leggibilità rispetto alla semplice organizzazione logica del codice. Ho visto molti spaghetti code illeggibili con una formattazione perfetta!

Non credo che ci sia una risposta semplice a questo. Non è una domanda sì o no. Mentre credo che lo stile e le convenzioni di denominazione siano importanti in una certa misura, è anche abbastanza facile perdere troppo tempo a pensarci. È meglio rispondere con l'esempio.

In un particolare progetto in cui mi trovavo, non c'erano affatto convenzioni. Ogni sviluppatore ha fatto le cose a modo suo. A causa della relativa inesperienza di questa squadra, passare da una classe all'altra era davvero sconvolgente. Lo stile era meno problematico del problema delle convenzioni di denominazione. Uno sviluppatore farebbe riferimento a elementi dell'interfaccia utente con una terribile notazione ungherese (una pratica sciocca nell'era dei moderni IDE), uno nominerebbe i membri privati ​​in un modo, un altro li nominerebbe in modo diverso. Non hai mai saputo cosa stavi guardando.

All'estremo opposto, un team ha usato StyleCop (questo era un progetto .Net) come parte del suo processo di compilazione. Quel che è peggio, è che hanno usato anche la maggior parte delle regole predefinite. Quindi faresti qualcosa di completamente normale in termini di spaziatura tra linee o posizionamento di parentesi graffe, e la build potrebbe vomitare a causa di essa. È stato sprecato così tanto tempo solo aggiungendo spazi e linee alle cose, e tutti, compresi i ragazzi che hanno insistito nell'usare StyleCop, hanno finito per fare quasi ogni commit. È stata un'enorme perdita di tempo e denaro.

Quindi il punto che sto sottolineando qui è che essere inflessibili non è la risposta, ma non essere neanche nel selvaggio West. La vera risposta è quella di trovare il posto più sensato, che secondo me è non avere strumenti automatici per controllare le cose, ma non gettare convenzioni al vento.

Il mio argomento principale contro lo stile di codifica comune è che un programmatore esperto viene utilizzato per leggere il proprio stile. Puoi allenare la mano a scrivere uno stile specifico, ma è quasi impossibile allenare l'occhio a capire uno stile che odi. Un programmatore scrive un pezzo di codice una volta e poi lo legge più volte durante lo sviluppo e il debug. Se ogni volta che legge il proprio codice fa fatica a capirlo poiché è stato costretto a scriverlo in uno stile BAD, sarà molto infelice e meno produttivo. Questo è dalla mia esperienza.

Non ho molta familiarità con Eclipse, ma il formato automatico sul salvataggio suona come un'idea orribile. Uno sviluppatore deve avere il controllo completo sul suo codice indipendentemente dal fatto che lo stile di codifica sia imposto o meno. L'operazione 'salva' non deve cambiare un singolo carattere senza il consenso esplicito dell'utente.

Se la tua azienda vende codice sorgente, lo stile di codifica è più importante, ma se vendi codice compilato è molto meno rilevante.

Sperare che lo stile di programmazione renderà il programmatore originale meno distinguibile e prevenga guerre dell'ego è una cazzata nel migliore dei casi e semplicemente stupida nel peggiore dei casi. I grandi programmatori produrranno sempre un codice elegante indipendentemente dallo stile.

Sono anche fortemente a favore di ogni proprietario degli sviluppatori di unità di codice specifiche e di non permettere a tutti di toccare liberamente ogni parte di codice. Lo sviluppo di intere unità nel codice e la loro responsabilità consentono allo sviluppatore di crescere con orgoglio nel suo lavoro e impedirgli di sviluppare codice scadente sapendo che i bug torneranno a cacciarlo.

Infine, chiunque abbia uno stile di codifica professionale presume sempre che il proprio stile di codifica verrà selezionato e tutti gli altri seguiranno. Immagina che lo stile di codifica che ti piace meno di tutti i tuoi co-sviluppatori sia selezionato come standard. Sei ancora favorevole all'imponente stile di codifica?

Un formato per dominarli tutti ... è davvero ottimale?

È come guidare la macchina di qualcun altro ...

Sicuramente puoi salire e guidare qualsiasi auto, ma sarai più sicuro, più a tuo agio e con meno probabilità di schiantarti se ti prendi il tempo di regolare il sedile, il volante e gli specchietti secondo le tue preferenze.

Con il codice, la formattazione influisce sul comfort durante la lettura e la comprensione del codice. Se è troppo lontano da ciò a cui sei abituato, richiederà più sforzo mentale. È necessario infliggere questo agli sviluppatori?

+1 a tutti i vantaggi menzionati finora, ma ...

L'applicazione automatica comporta costi che devono essere considerati:

-1 al fatto che i formattatori di codice non comprendono l'estetica della formattazione del codice. Quante volte hai fatto in modo che un formattatore di codice distruggesse un blocco di commenti che era ben allineato in una forma tabulare? Quante volte hai intenzionalmente allineato un'espressione complessa in un certo modo per aumentare la leggibilità, solo per avere la formattazione automatica trasformarla in qualcosa che "segue le regole", ma è molto meno leggibile?

A volte ci sono soluzioni alternative a queste cose, ma gli sviluppatori hanno cose più importanti a cui pensare rispetto a come impedire al formatter automatico di alterare il codice.

Hanno regole di formattazione, ma consentono alla libertà di applicare il buon senso.

I buoni sviluppatori sono persone creative, date loro una licenza artistica. "Keep it simple" dovrebbe essere il mantra dei programmatori. Ho due regole:

Regola 1: fornire variabili / cursori / oggetti / procedure / qualunque NOME SENSIBILE. Nomi inequivocabili che portano significato e comprensione al tuo codice.

Regola 2: utilizzare il rientro per mostrare la struttura del codice.

Questo è tutto.

Per me, il vantaggio principale di un formato comune applicato automaticamente è che aiuta il nostro rilevamento delle modifiche e le revisioni del codice. git (e la maggior parte degli altri strumenti di controllo del codice sorgente) può mostrare differenze nelle versioni precedenti dei file. Applicando uno stile comune, minimizzando le differenze nelle preferenze del programmatore.

Le guide di stile facilitano inoltre l'analisi programmatica del codice per vari scopi analitici.

Google ha pubblicato un documento su questo chiamato "Ricerca del debito accumulato: esperienze nella gestione del debito tecnico su Google" .

Sono le lingue, non i codici. Noi umani abbiamo più di 6000 lingue, quindi le traduciamo. Quindi, se vuoi che i tuoi "codici" comunichino, dovrai apportare le tue modifiche. Vedete, noi utenti dobbiamo modificare i nostri formati di dati in modo da non perdere i nostri dati.

Direi che non lo è. Una struttura / formato di codice comune in un team è sicuramente una buona cosa, ma non lo fa automaticamente applicarlo. Questo dovrebbe essere fatto dagli umani, non dal computer.

I miei maggiori problemi con il concetto sono

1. Se sto scrivendo un codice in un formato e questo viene automaticamente riformattato, quale incentivo c'è davvero per imparare quel formato?
2. A seguito di quel punto precedente, se non si impara il formato, l'intero punto della formattazione automatica (per rendere il codice più facile da leggere e modificare) viene completamente perso. Devi ancora prendere tempo per capire la formattazione mentre stai leggendo il codice perché non hai imparato quel formato
3. Penso che sarebbe un'esperienza stonante come sviluppatore scrivere un corso un giorno, chiuderlo e tornare il giorno successivo per vedere che è completamente diverso. Ciò significa che non solo gli altri devono imparare il tuo codice, ma devi anche imparare il tuo codice.
4. Potrebbe anche incoraggiare la codifica pigra. Invece di spingere lo sviluppatore a imparare il formato, possono scrivere in qualsiasi formato sotto il sole e sembrerà automaticamente come tutti gli altri lo desiderano. Questo risale al n. 2 dove non impari lo stile e non riesci ancora a leggerlo correttamente.

Ora, potrei essere propenso a dire che eseguire un auto-formattazione su un progetto che è tutto concluso sarebbe una buona idea. Ciò avvierebbe ogni sviluppatore con lo stesso piede per il progetto quando vai a correggere / aggiungere funzionalità in seguito. Durante lo sviluppo attivo, tuttavia, penso che sia una scelta molto scarsa.

Fondamentalmente: affidare al dipendente la responsabilità di apprendere lo stile dell'azienda, non forzare il proprio codice ad essere qualcosa che non lo è.