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

Cosa fai quando lavori con qualcuno che tende a scrivere un codice stilisticamente cattivo? Il codice di cui sto parlando è di solito tecnicamente corretto, ragionevolmente strutturato e può anche essere algoritmicamente elegante, ma sembra brutto . Abbiamo:

• Miscela di convenzioni e titoli di denominazione diversi ( underscore_stylee camelCasee UpperCamele CAPStutti applicati più o meno a caso a variabili diverse nella stessa funzione)
• Spaziatura bizzarra e incoerente, ad es Functioncall (arg1 ,arg2,arg3 );
• Molte parole errate nei commenti e nei nomi delle variabili

Abbiamo un buon sistema di revisione del codice in cui lavoro, quindi guardiamo e sistemiamo le cose peggiori. Tuttavia, è davvero meschino inviare una recensione di codice che consta di 50 righe di "Aggiungi uno spazio qui. Scrivi correttamente" itarator ". Cambia questa maiuscola, ecc."

Come incoraggeresti questa persona a essere più attenta e coerente con questo tipo di dettagli?

Concordare una convenzione di codifica

Anche se questo è un cercapersone. Suggerisco a tutto il team di sedersi e concordare tutti sulla convenzione di base sulla codifica di lavoro utilizzabile da tutto il team.

Penso che devi solo continuare a fare quello che stai facendo. Avere una serie chiara 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 "Correggi" iteratore "correttamente" ogni volta che tenta di eseguire il check-in di qualcosa, e in realtà non gli è consentito effettuare il check-in prima che tutti vengano risolti, alla fine egli dovrò iniziare a scrivere codice più pulito solo per evitare il fastidio.

Penso che se aggiusti queste cose da solo, come suggerito da NimChimpsky, pulirai per sempre questa persona.

Chiamo BS su tutti coloro che hanno affermato che gli errori di ortografia e la formattazione dei nomi variabili non contano. Ovviamente, hanno letto solo il loro codice. E nota quella parola proprio lì: leggi. Immagina di leggere un libro con molti errori di ortografia, formattazione pasticciata, spaziatura delle linee incoerente e varie altre pigrizie prevalenti in molti codici sorgente. Sarebbe noioso.

Per una professione in cui la sintassi deve essere corretta al 100% per funzionare, non c'è semplicemente alcuna scusa per qualsiasi sviluppatore reale di non avere uno stile di codice pulito e coerente. Qualcos'altro è trasandatezza e pigrizia. Metto sempre in dubbio la correttezza del codice scarsamente formattato nell'implementazione.

Abbiamo un buon sistema di revisione del codice in cui lavoro, quindi guardiamo e sistemiamo le cose peggiori. Tuttavia, è davvero meschino inviare una recensione di codice che consta di 50 righe di "Aggiungi uno spazio qui. Scrivi correttamente" itarator ". Cambia questa maiuscola, ecc."

Lo cambierei da solo e aggiungerei un commento educato nel codice.

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

Abbiamo un buon sistema di revisione del codice

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

Penso che convenzioni come la denominazione di classi e variabili siano importanti e debbano essere seguite anche con un codice elegante ed efficiente, ma a rischio di sottoporre a votazione negativa la mia risposta molte volte, devo dire che in generale il paradigma del "bel codice" che è spinto molto in giro, è in IMHO molto sopravvalutato.

Prima di tutto, lo sviluppatore che lo ha scritto dovrà mantenerlo in primo luogo, e se mai viene colpito da un autobus e un altro programmatore non riesce a capire come funziona perché il codice non è "carino", direi che l'altro sviluppatore non è comunque molto bravo. E ci sono molti formattatori / abbellitori automatizzati là fuori, quindi chiunque può usarli per abbellire il codice se necessario, senza perdere tempo pur essendo "nel flusso" / "nella zona".

Si prega di notare che non sto sostenendo la codifica di spaghetti / stile cowboy qui, infatti ho visto un codice spaghetti formattato molto bene (corpi funzione che coprono 4-5 schermate, variabili globali sparse in diversi file di codice sorgente, generalmente cattive scelte di nomi , eccetera).

Uno dei miei colleghi scrive HTML in modo tale da farmi strisciare la pelle. Immagina il mio html bello e strutturato con due rientri spaziali, fatto a pezzi da tag aggiunti alla fine del mio che finiscono sulla stessa linea o sul prossimo come un ubriaco che ha bisogno di gettare un braccio intorno a te 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 fuori valori di temperatura irrazionali in modo tale che in qualche modo le sue cifre rispecchino il numero di spazi o schede utilizzati in tale rientro da questa donna. Se sono fortunato, vedrò un tag di input chiuso con " </input>". Incubo totale che puoi capire.

Nessuno sembra capirlo neanche, visto che per la maggior parte dei superiori qui, il codice organizzato o il codice non organizzato per loro è come la differenza tra noi che mettiamo il formaggio svizzero o il formaggio americano sui nostri panini, vale a dire che potrebbero davvero fregarsene di meno. Ho iniziato a lasciarlo scivolare perché ero stressato da un altro progetto e penso che abbia iniziato a rendersi conto di quanto fosse difficile capire un codice del genere prima di voler migliorare. Il mio consiglio sarebbe di dimostrare perché è preferibile dare uno stile al tuo codice piuttosto che semplicemente dire loro di farlo.

Il codice di cui sto parlando è di solito tecnicamente corretto, ragionevolmente strutturato e può anche essere algoritmicamente elegante ...

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

Sembra che tu debba creare e accettare una convenzione di stile. In caso contrario, avrai librerie con 3 rientri di spazio, altre con 4, alcune che usano Camel Case e altre che usano underscore_case.

Le modifiche che desideri rendere le tue preferenze personali o hai uno standard effettivo da seguire? Se non disponi di uno standard attuale, non farlo. Innanzitutto stabilire uno standard. Quindi è possibile ottenere software che può essere impostato per il refactoring del codice in base alle impostazioni dello standadrd (almeno per alcune cose).

Se disponi di uno standard, inizia ad applicarlo nella revisione del codice. Non ha senso avere uno standard se non lo si applica nella revisione del codice. Ciò significherà un sacco di lavoro extra nella manutenzione poiché le persone dovranno riparare il vecchio codice che non ha soddisfatto lo standard inizialmente quando lo toccano.

Anche senza uno standard, insisti a correggere gli errori di ortografia nei nomi delle variabili (non mi preoccuperei particolarmente dei commenti) poiché faranno impazzire tutti coloro che toccano il codice per sempre.

Gli standard di codifica devono essere identificati in modo che tutti sappiano cosa sono e quindi devono essere applicati. Dovrebbero esserci conseguenze nel non seguire le regole.

Ecco le cose che dovrebbero fornire qualche incentivo:

1. Le revisioni del codice saranno noiose e più lunghe del necessario.
2. Il codice verrà rifiutato più spesso.
3. Gli orari non saranno rispettati.

Se questa persona o non deve preoccuparsi di questo perché nessuno applica le tue regole o non gli importa se sono improduttivi (e nessuno fa nulla al riguardo), non c'è molto che puoi fare al riguardo.

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

1. Il collega è affrettato e perché qualcuno ha voluto il codice ieri, la persona sta cercando di far funzionare qualcosa il più velocemente possibile? Questa può essere un'opportunità per informare questa persona di concentrarsi più sulla qualità che sulla velocità nel proprio lavoro. Un mantra come "Prenditi il ​​tuo tempo" potrebbe essere utile se questo non è controproducente.

2. In che modo la persona vede il proprio lavoro? Se c'è un senso di orgoglio, allora potresti avere un angolo da usare per ottenerne uno da migliorare. Se è solo un lavoro che paga le bollette, potrebbe essere molto più difficile ottenere modifiche. 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 per protestare? Se è così, allora potresti avere un grosso problema, ma vale la pena scoprire se è così o la persona è semplicemente pigra? Quali tipi di motivazione possono essere utili qui, ad esempio potresti fare appello all'avidità, all'orgoglio o ad altri vizi per far migliorare la persona. Questo è subdolo ma forse efficace se provare il percorso del bravo ragazzo non ne ottiene uno da nessuna parte.

4. Come conquistare amici e influenza Le persone hanno alcuni suggerimenti in termini di persuasione che possono funzionare, come lodare i miglioramenti e dare alla persona un'ottima reputazione da difendere.

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

1. C'è una buona possibilità di umiliazione, critica o altra spiacevolezza che è meglio tenere dietro una porta piuttosto che essere lasciato all'aperto, dove qualcuno potrebbe sentire il loro personaggio assassinato.

2. Vuoi incoraggiare quest'altra persona ad aprirsi un po '. Una sfida qui è che alcune persone sono così sorvegliate che può richiedere molto tempo per farle abbattere 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 l'ambiente circostante sia abbastanza modificato da far sentire la persona un po 'più a suo agio. Questa può essere una sfida e richiede la conoscenza della persona, ma l'idea qui è che in ufficio alcune persone indosseranno una maschera da lavoro che probabilmente non sarà utile qui.

4. Preparati a rendere la conversazione piuttosto brutta o brutta, ma questo potrebbe essere un buon segno se riesci a mantenere l'altra persona impegnata e avere un buon dialogo. Ad alcune persone piace tenere le cose all'aperto e altre potrebbero preferire modi più sottili per farlo. La chiave è assicurarsi di ascoltare l'altra persona abbastanza per entrare in empatia e cercare di capire il loro lato.

Abbiamo un test JUnit che cerca problemi di formattazione. Funziona come parte della build. Continuo a mordere omettendo uno spazio tra if, while o for e la parentesi aperta. Tuttavia, il nostro codice è costantemente formattato.

http://code.google.com/p/kawala/wiki/BadCodeSnippetsRunner

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

Se si utilizza Eclipse, abilitare Salva azioni per i redattori Java e dire a tutti di usarlo. Questo risolve i problemi di formattazione ad ogni salvataggio, ma non corregge le maiuscole. Potrebbe essere abbastanza utile!

Quanto è difficile seguire le convenzioni di stile? Comprendo gli errori di ortografia, ma il resto è un indicatore del pensiero sciatto e della codifica. Spiega alla persona che deve essere più coerente quando si tratta di codice di produzione perché non sono i soli a guardarlo. Scrivere codice di produzione in uno stile incoerente è semplicemente maleducato, egoista e sconsiderato.

LOL. Odierai assolutamente il mio codice. Non posso scrivere per salvarmi la vita e non mi interessa.

Ma so che ad alcune persone interessa davvero queste cose.

Ti suggerisco di licenziare la persona che scrive quel brutto codice se non cambiano, quindi trova qualcuno che renda le cose davvero belle e spero che possano scrivere codice che

di solito è tecnicamente corretto, ragionevolmente strutturato e può anche essere algoritmicamente elegante

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

Ma sul serio. Concentrati prima sulle cose realmente importanti. Se non riesci a trovare una buona e solida ragione al di fuori di "fa male alla mia delicata sensibilità", ignoralo per ora. Se in realtà è importante, siediti con la persona e convincili di quella importanza. Cose come gli standard che rendono facile distinguere tra livello di classe, livello di metodo, variabili condivise e costanti fanno la differenza. Se il programmatore in questione si prende cura della sua professione, capirà e proverà a fare la cosa giusta.

La mia soluzione quando ho a che fare con risorse esternalizzate che non davano un &% $ # sulla formulazione (o bug facilmente prevenibili per quella materia) era di far applicare il server di compilazione. Ho creato un lavoro del server CI che veniva eseguito ogni notte che controllava il codice, eseguiva Jalopy e findbugs, quindi controllava nuovamente il codice. Una volta che l'altro team venne a sapere che non usare le convenzioni del codice standard avrebbe reso il loro lavoro più difficile, iniziarono a usare il loro IDE per mantenere un formato standard.