Perché le squadre insistono ancora su una politica di stile del codice? [chiuso]

Facile, perché una guida di stile (non una guida allo stile) copre molto di più dell'imposizione di 2 o 4 spazi.

Prendi ad esempio il codice google java styleguide .

Sì, ci sono alcuni paragrafi sull'indentazione, ma molti altri argomenti sono trattati.

Why doesn't Google just write a script that upon git commit or git push, it re-formated to Google's main standard, and let everyone program how they want.

Perché non importa quanto sia buono un riformattatore, in fin dei conti si tratta di uno strumento stupido e automatizzato, privo di informazioni, intelligenza e creatività. Il risultato finale quando si applica un programma di formattazione a un progetto senza stili di codifica è assolutamente orribile.

Un altro problema è che la riformattazione spesso introduce modifiche artificiali nel repository CM. Supponiamo di aver apportato una piccola modifica a una riga di un file lungo 1000 righe. Supponiamo di aver anche riformattato da un rientro di 2 caratteri a un rientro di 8 caratteri, mantenendo un limite di 80 caratteri. Trovare quale linea hai cambiato non è un compito da poco. git blame dirà che hai cambiato ogni singola riga nel file.

Lo stile di indentazione, in un certo senso, è "roba piccola" e una delle prime regole guida di stile dovrebbe essere la regola "Non ingannare le piccole cose". Questa regola si applica agli autori delle guide di stile e ai programmatori. Gli autori delle guide di stile non dovrebbero creare regole che facciano sudare le piccole cose; le persone rimarranno contro quelle regole e le ignoreranno. (La maggior parte delle guide di stile per la codifica sono piene zeppe di regole che fanno sudare le piccole cose.)

Per quanto riguarda i programmatori, quei programmatori che devono riformattare il codice in base al loro stile personale per comprendere il codice non sono dei buoni programmatori. Un buon programmatore dovrebbe essere in grado di leggere, capire e modificare il codice che è formattato in modo coerente con uno stile ragionevole, e fare a meno di dover cambiare indentazione, parentesi graffe, ecc.

Le mie regole sono state semplici nelle occasioni in cui ero stato il re della collina ed ero in grado di scrivere gli standard per un progetto: coerenza tra i moduli, con stile di indentazione e importo scelto da un ragionevole insieme di opzioni.

Penso che il problema riguardi davvero la qualità delle guide di stile. C'era un famoso C ++ che era lungo centinaia di pagine - uno scherzo di curiosità e minuzie che non avrebbe mai aiutato il lavoro di squadra. Ho visto una guida di stile complessa che conteneva tutti i tipi di regole, assolutamente inutile (tranne quando il tizio che ha scritto la guida non ha seguito le sue stesse regole ... è stato divertente).

Ma questo tipo di guide è utile ad un certo punto: il codice dovrebbe almeno provare ad apparire uguale così non ci sono stili strani e meravigliosi che qualcuno introduce perché ne ha voglia (ho visto tutti i tipi di chiamate di funzioni, parentesi qui e lì, rientri 2 spazi, 3 spazi, schede ecc.). Questa mancanza di stile rende difficile la lettura del codice. Provalo qualche volta - la prossima volta che aggiungi una modifica al tuo codice, scegli una larghezza di rientro diversa. Garantisco che non sarai in grado di tracciare i blocchi di codice dopo solo 2 o 3 modifiche.

Personalmente penso che le guide di stile dovrebbero essere "fai come appare il codice al momento" quindi non c'è bisogno di piccole restrizioni e consente eccezioni leggibili alla regola (come sarà sempre presente)