Correzione automatica del codice, buona o cattiva? [chiuso]

we are still in transition of team of developers who write code, to team of developers who understands what writing good code means.

Indovina cosa - non lascerai mai quel percorso di transizione (perché anche se programmassi per più di un decennio, puoi ancora imparare qualcosa su una codifica migliore)! Quindi fai un favore alla tua squadra, lascia che usino il tuo strumento ora, ma assicurati che le persone facciano un confronto con il modo in cui il codice appare prima e in seguito per imparare qualcosa da questo . Potrebbe anche essere una buona idea introdurre il tuo team nello strumento spiegando ogni tipo di miglioramento del codice che fa e il ragionamento che lo sta dietro.

Quando aspetti di introdurre questo strumento finché i tuoi sviluppatori non arrivano al punto in cui scrivono solo codice "perfetto", probabilmente non avranno più bisogno del tuo strumento.

Direi: Probabilmente buono per la produttività della tua azienda; ma potenzialmente negativo per le carriere dei tuoi sviluppatori.

È probabilmente utile per la produttività della tua azienda perché, in un certo senso, tutto il codice viene "riscritto" prima dell'esecuzione. L'aggiunta di un altro livello di riscrittura può essere considerata una mutazione o estensione della lingua. E se le estensioni aiutano la produttività, va bene. Infatti, congratulazioni, hai creato un nuovo dialetto. (hooray ...)

Tuttavia, è probabilmente buono per la produttività della tua azienda perché certe "estensioni linguistiche" possono favorire la sciatteria o anche solo "un diverso modo di pensare" che si estende in aree di quel codice che non viene riscritto, o forse non può essere riscritto.

È potenzialmente dannoso per le carriere dei tuoi sviluppatori perché potrebbero abituarsi a scrivere una sottolingua che utilizza solo la tua organizzazione. Se i tuoi sviluppatori non sono incoraggiati a "scrivere bene" secondo gli standard predominanti, stai potenzialmente danneggiando le loro future carriere - oh così poco.

Detto questo, incoraggerei l'incorporazione di estensioni di cui i tuoi sviluppatori sono pienamente consapevoli e che riscrivono solo il codice allo scopo di aumentare la produttività espandendo il codice condensato . Le estensioni non dovrebbero "correggere" il codice rotto, permettendo agli sviluppatori di ignorare beatamente che il loro codice è sbagliato; le estensioni dovrebbero avvertire o fallire codice errato.

Per essere chiari: le tue estensioni dovrebbero essere chiamate estensioni e dovrebbero essere solo nel business di prendere "brevi cose" ben documentate ed estenderle " cose un po 'più lunghe. "

La correzione del codice è come il completamento automatico o il formato automatico, uno strumento che aiuta gli sviluppatori a non preoccuparsi delle minuzie del codice e a concentrarsi maggiormente su ciò che dovrebbe fare.

Tuttavia dare una correzione del codice a un dev che non comprende la sintassi è come dare un modo automatico per iniziare gli anglofoni, il risultato sarà spesso leggibile / comprensibile ma raramente corretto. (Risultante nella sostituzione ormai popolare di "ratchet" per "wretched" )