Trattare con colleghi che non hanno uno stile di codifica coerente?

Accetta una convenzione di codifica

Anche se si tratta di un solo cercapersone. Suggerisco che tutto il team si sieda e tutti siano d'accordo sulla convenzione di base del codice di lavoro che l'intero team può usare.

Penso che devi solo continuare a fare quello che stai facendo. Avere un chiaro insieme di linee guida per la codifica e applicarle durante le revisioni del codice. Se uno sviluppatore ottiene 50 o 100 righe di "Aggiungi uno spazio qui" e "Spell 'iteratore" correttamente "ogni volta che cerca di controllare qualcosa, e in realtà non gli è permesso di registrarsi prima che tutti vengano sistemati, alla fine lui Dovrò iniziare a scrivere codice più pulito solo per evitare problemi.

Penso che se tu aggiusti queste cose da te, come suggerito da NimChimpsky, ripulirai per sempre da questa persona.

Chiamo BS a tutti coloro che hanno affermato che gli errori di ortografia e la formattazione dei nomi delle variabili non hanno importanza. Ovviamente, hanno solo letto il loro codice. E nota quella parola proprio lì - leggi. Immagina di leggere un libro con un sacco di errori di ortografia, formattazione mish-mashed, interlinea incoerente e varie altre pigrizie prevalenti in un sacco di codice sorgente. Sarebbe noioso.

Per una professione in cui la sintassi deve essere corretta al 100% per funzionare, non c'è semplicemente alcuna scusa per nessuno sviluppatore reale che non abbia uno stile di codice pulito e coerente. Qualsiasi altra cosa è la sciatteria e la pigrizia. Ho sempre messo in dubbio la correttezza del codice formattato in modo inadeguato nell'implementazione.

We have a good code review system where I work, so we do get to look over and fix the worst stuff. However, it feels really petty to send a code review that consists of 50 lines of "Add a space here. Spell 'itarator' correctly. Change this capitalization. etc."

Lo cambierei io stesso e quindi aggiungo un commento educato nel codice.

questo presuppone che ci sia già una guida di stile come la domanda dichiarata:

We have a good code review system

Quindi il mio suggerimento è l'ultima risorsa, immagino che sia altrettanto veloce cambiarlo da solo e lasciare un commento, poiché è per inviare una e-mail o altro.

Penso che le convenzioni come la denominazione di classi e variabili siano importanti e debbano essere seguite da un codice elegante ed efficiente, ma a rischio di far decollare la mia risposta molte volte, devo dire che in generale il "bel codice" "Il paradigma che viene spinto molto è in IMHO molto sopravvalutato.

Prima di tutto, lo sviluppatore che l'ha scritto dovrà mantenerlo in primo luogo, e se è mai investito da un autobus e un altro programmatore non può capire come funziona perché il codice non è "carino", io d dire che l'altro sviluppatore non è comunque molto bravo. E ci sono molti formattatori / abbellitori automatici là fuori, quindi chiunque può usarli per abbellire il codice se necessario, senza perdere tempo mentre si trova "nel flusso" / "nella zona".

Si noti che non sto promuovendo la codifica spaghetti / cowboy qui, infatti ho visto alcuni codici spaghetti molto ben formattati (corpi di funzioni che coprono 4-5 schermi, variabili globali sparse su diversi file di codice sorgente , in genere scelte sbagliate di nomi, ecc.)

Uno dei miei colleghi scrive html in modo tale da far strisciare la mia pelle. Immagina il mio html bello e strutturato con due rientri spaziali, tagliato a pezzi da tag aggiunti alla fine dei miei che finiscono sulla stessa riga o sull'altro come un ubriaco che ha bisogno di gettarti un braccio attorno per rimanere in piedi. Le nuove linee sono raramente rientrate, ma se lo sono, sono sicuro che ci sia un buco nero altamente caotico in qualche parte della galassia che sputa valori di temperatura irrazionali in modo tale che in qualche modo le sue cifre rispecchiano il numero di spazi o tabulazioni usati in tale indentazione da questa donna Se sono fortunato, vedrò un tag di input che viene chiuso con " </input> ". Incubo totale che puoi capire.

Anche nessuno sembra capirlo, visto come per la maggior parte degli alti qui, codice organizzato o codice non organizzato per loro è come la differenza tra noi mettere formaggio svizzero o formaggio americano sui nostri panini, vale a dire, potrebbero davvero preoccuparsene Di meno. Ho iniziato a lasciarlo scivolare perché ero stressato con un altro progetto, e penso che abbia iniziato a capire quanto fosse difficile capire un codice del genere prima che volesse migliorare. Il mio consiglio è di dimostrare perché è preferibile dare uno stile al codice più che semplicemente dire loro di farlo.

The code I'm talking about is usually technically correct, reasonably structured, and may even be algorithmically elegant...

Sii felice di aver ottenuto tutto questo. La maggior parte dei programmatori forse ti darà la prima cosa in quella lista. Penso che la variabile denominazione e spaziatura sia la cosa meno importante di cui preoccuparsi.

Sembra che tu abbia bisogno di impostare e accettare una convenzione di stile. Se non lo fai avrai librerie che hanno 3 indentati nello spazio, altre che ne hanno 4, altre che usano Camel Case e altre che usano underscore_case.

Le modifiche si desidera rendere personali le tue preferenze o hai uno standard effettivo da seguire? Se non hai uno standard attuale, non farlo. Prima stabilisci uno standard. Quindi è possibile ottenere un software che può essere impostato per rifattorizzare il codice alle impostazioni standadrd (beh, almeno su alcune cose).

Se hai uno standard, inizia ad applicarlo nella revisione del codice. Non ha senso avere uno standard se non lo si impone nella revisione del codice. Ciò comporterà un sacco di lavoro extra in manutenzione, in quanto le persone dovranno correggere il vecchio codice che non ha soddisfatto lo standard originariamente quando lo toccano.

Anche senza uno standard, insisti a correggere i mispellings nei nomi delle variabili (non mi preoccuperei particolarmente dei commenti) poiché guideranno tutti coloro che toccano il codice impazzendo per sempre.

Gli standard di codifica devono essere identificati in modo che tutti sappiano cosa sono e quindi devono essere applicati. Ci dovrebbero essere conseguenze per non seguire le regole.

Ecco le cose che dovrebbero fornire qualche incentivo:

1. Le recensioni dei codici saranno noiose e più lunghe del necessario.
Il codice
2. verrà rifiutato più spesso.
3. Gli orari non verranno soddisfatti.

Se questa persona non deve preoccuparsi di questo perché nessuno impone le tue regole o non gli importa se sono improduttive (e nessuno fa niente al riguardo), non c'è molto che tu possa fare al riguardo.

Sarei tentato di suggerire di avere una chat privata e vedere se entrambi potresti trovare una causa principale:

1. Il collaboratore si è affrettato e perché qualcuno voleva il codice ieri la persona sta cercando di ottenere qualcosa che funzioni il più velocemente possibile? Questa può essere un'opportunità per informare questa persona a concentrarsi più sulla qualità che sulla velocità nel proprio lavoro. Un mantra come "Prendi il tuo tempo" potrebbe essere utile se non è controproducente.

2. In che modo la persona vede il loro lavoro? Se c'è un senso di orgoglio, allora potresti avere un angolo da usare per farti migliorare. Se è solo un lavoro che paga le bollette, potrebbe essere molto più difficile ottenere cambiamenti. Sanno che non stanno facendo un ottimo lavoro ma sono così vicini?

3. Questa persona non è d'accordo con le convenzioni e sta cercando di codificare in segno di protesta? Se è così, allora potresti avere un grosso problema, ma vale la pena scoprire se questo è il caso o se la persona è semplicemente pigra? Quali tipi di motivazione possono essere utili qui, ad es. potresti fare appello all'avidità, all'orgoglio o ad altri vizi per far migliorare la persona. Questo è subdolo, ma probabilmente efficace se si cerca il percorso del bel ragazzo non si ottiene da nessuna parte.

4. Come conquistare gli amici e influenzare le persone ha alcuni suggerimenti in termini di persuasione che può funzionare, come lodare i miglioramenti e dare alla persona una buona reputazione da difendere.

Per quanto riguarda il motivo per cui questo deve essere fatto in privato, ecco alcuni motivi:

1. Ci sono buone probabilità di umiliazione, critica o altre spiacevoli condizioni che vengono tenute dietro una porta piuttosto che lasciate all'aperto dove qualcuno potrebbe sentire assassinato il proprio personaggio.

2. Vuoi incoraggiare quest'altra persona ad aprirsi un po '. Una sfida qui è che alcune persone sono così sorvegliate che può impiegare molto tempo per indurle a demolire i loro muri.

3. Se possibile, suggerirei di provare a farlo un po 'lontano dall'ufficio. Esci a pranzo, fai una passeggiata o fai qualcosa in modo che i dintorni siano abbastanza alterati da rendere la persona un po 'più a suo agio. Questa può essere una sfida e richiede conoscere la persona, ma l'idea qui è che in ufficio alcune persone indossano una maschera di lavoro che non è probabilmente utile qui.

4. Siate pronti a rendere la conversazione piuttosto calda o brutta, ma questo potrebbe essere un buon segno se potete mantenere l'altra persona impegnata e avere un buon dialogo. Ad alcune persone piace tenere fuori le cose allo scoperto e altri potrebbero preferire modi più sottili di fare le cose. La chiave è assicurarsi di ascoltare l'altra persona abbastanza per entrare in empatia e cercare di capire la loro parte.

Abbiamo un test JUnit che cerca i problemi di formattazione. Funziona come parte della build. Mi capita continuamente di omettere uno spazio tra if, while o for e la parentesi di apertura. Il nostro codice è comunque formattato in modo coerente.

link

L'abbellimento del codice come unscrutify sarà in grado di risolvere alcuni dei tuoi problemi. Se sei pronto a pagare per questo, ci sono software di alto livello che incorporano le regole nel codice sorgente stesso come Parasoft . Parasoft rende obbligatorio scrivere il codice in uno stile uniforme. Puoi incorporare anche le tue regole. Quando vengono utilizzati tali strumenti, gli sviluppatori sono costretti a utilizzare uno stile uniforme. E dopo un po 'ci si abitueranno.

Se si utilizza Eclipse, abilitare Salva azioni per gli editor Java e indicare a tutti di usarlo. Questo risolve i problemi di formattazione su ogni salvataggio, ma non risolve le maiuscole errate. Potrebbe essere abbastanza utile però!

Quanto è difficile seguire le convenzioni di stile? Capisco gli errori di ortografia, ma il resto è un indicatore di pensiero e codifica sciatti. Di 'alla persona che devono essere più coerenti quando si tratta del codice di produzione perché non sono gli unici a guardarlo. È semplicemente scortese, egoista e sconsiderato scrivere codice di produzione in uno stile incoerente.

LOL. Oserei assolutamente il mio codice. Non posso scrivere per salvare la mia vita e non mi interessa.

Ma so che alcune persone si preoccupano davvero di queste cose.

Ti suggerisco di licenziare la persona che scrive quel brutto codice se non cambia, poi trova qualcuno che rende le cose davvero belle e spera che possano scrivere codice che

is usually technically correct, reasonably structured, and may even be algorithmically elegant

e se non possono, almeno puoi mostrare il codice carino rotto al cliente e venderli su quello!

Ma sul serio. Concentrati prima sulle cose veramente importanti. Se non riesci a trovare una buona, solida ragione al di fuori "mi fa male la mia delicata sensibilità", allora ignorala per ora. Se è davvero importante, siediti con la persona e convincili di questa importanza. Cose come standard che rendono facile distinguere tra livello di classe, livello di metodo, variabili condivise e costanti fanno la differenza. Se il coder in questione si preoccupa della sua professione, capirà e cercherà di fare la cosa giusta.

La mia soluzione quando si trattava di risorse in outsourcing che non davano un &% $ # sulla formulazione (o bug facilmente prevenibili per quella materia) era che il build server la imponesse. Ho creato un lavoro del server CI che veniva eseguito ogni notte che controllava il codice, eseguiva Jalopy e findbugs, quindi ricontrollava il codice. Una volta che l'altro team apprese che non usare le convenzioni standard del codice avrebbe reso il loro lavoro più difficile, iniziarono a usare il loro IDE per mantenere un formato standard.