Come posso trattare con un membro del team a cui non piace fare commenti in codice?

Uno dei membri del mio team evita costantemente di fare commenti nel suo codice.

Il suo codice non è auto-documentante e altri programmatori hanno difficoltà a comprendere il suo codice.

Gli ho chiesto più volte di commentare il suo codice, tuttavia egli fornisce solo scuse o affermazioni che lo farà in seguito. La sua preoccupazione è che l'aggiunta di commenti richiederà troppo tempo e ritarderà i progetti.

Quale argomento posso presentargli per convincerlo a documentare correttamente il suo codice?

In tale nota, sbaglio a concentrarmi sui commenti del codice o è indicativo di un problema più ampio che dovrebbe essere affrontato?

I commenti da soli non rendono il codice migliore, e semplicemente spingendo per "più commenti" è probabile che ti dia poco più che /* increment i by 1 */commenti di stile.

Quindi chiediti perché vuoi quei commenti. "È la migliore pratica" non conta come argomento se non capisci il perché.

Ora, la ragione più eclatante per l'uso dei commenti è che il codice è più facile da capire, e quando le persone si lamentano della mancanza di commenti, sono o pappagalli all'oscuro, o fanno fatica a capire il codice con cui stanno lavorando.

Quindi non lamentarti dei commenti mancanti: lamentati del codice illeggibile. O meglio ancora, non lamentarti, continua a fare domande sul codice. Per tutto ciò che non capisci, chiedi alla persona che l'ha scritto. Dovresti farlo comunque; con codice illeggibile, farai solo altre domande. E se torni a un pezzo di codice più tardi e non sei sicuro di ricordare correttamente cosa fa, fai di nuovo la stessa domanda.

Se i commenti possono risolverlo e il tuo collega ha un cervello funzionante, a un certo punto si renderà conto che commentare il codice è molto più facile che farti fare domande stupide in ogni momento. E se non riesci a formulare domande, allora forse quel codice è già perfettamente leggibile, ed è tu che sei in errore - dopo tutto, non tutto il codice ha bisogno di commenti.

Sul fronte delle abilità delle persone, evitare di sembrare condiscendente o accusare a tutti i costi; sii serio e onesto con le tue domande.

Ho incontrato molti sviluppatori che hanno avuto problemi a scrivere codice autocompattante o commenti utili. Questo tipo di persone spesso manca di sufficiente autodisciplina o esperienza per farlo bene.

Ciò che non funziona mai è "dire loro di aggiungere altri commenti". Ciò non aumenterà né la loro autodisciplina né esperienza. L'IMHO l'unica cosa che potrebbe funzionare è fare frequenti revisioni del codice e sessioni di refactoring. Quando uno sviluppatore ha completato un'attività, consenti a lui / lei di spiegare eventuali parti del codice che non capisci. Rifattorizzare o documentare immediatamente il codice in modo tale che entrambi capirai 6 mesi dopo.

Fallo per alcuni mesi, almeno due volte a settimana. Se sei abbastanza fortunato, gli altri sviluppatori impareranno attraverso queste sessioni in modo da poter ridurre la frequenza di revisione.

Sono sorpreso che nessuno abbia ancora menzionato le recensioni dei codici. Fai recensioni di codice! Quando ha un check in di cattiva qualità non dire semplicemente "aggiungi commenti". Poni costantemente domande e fagli dire cosa fa il suo codice e perché. Prendi nota. Quindi, alla fine della revisione del codice, dagli una copia delle note e digli di rendere le tue domande abbastanza ovvie. O con più commenti o semplicemente riformattando il suo codice per renderlo migliore qualità (preferibilmente quest'ultimo quando possibile)

Questo dipende dal codice prodotto dal tuo collaboratore. Se leggi il libro Clean Code di zio Bob, scoprirai che in realtà preferisce non aggiungere commenti al codice. Se il codice stesso è leggibile come dovrebbe essere, allora non c'è quasi bisogno di commenti.

Se questo non è il caso, o hai bisogno di commenti a causa di una politica non negoziabile, la domanda principale diventa se sei solo tu che vuoi che scriva commenti, o se è l'intero team o il team / progetto capo. Se sei solo tu, allora dovresti parlare con gli altri colleghi per scoprire perché potrebbe non essere affatto un grosso problema.

Se il leader del progetto non ha commenti, è possibile richiederli anche come parte della completezza , ovvero se il codice inviato non ha commenti, il lavoro non è ancora finito. Non può continuare a fare altri lavori, fino a quando il suo lavoro attuale non è finito e per questo sono richiesti commenti. Tuttavia, tieni presente che questo tipo di forzatura molto probabilmente porterà a commenti orribili (aspettati un sacco di schifose ripetizioni di commenti di codice).

L'unico modo possibile secondo la mia modesta opinione è di discutere dei profitti reali che tu e tutti gli altri ottenete dai commenti. Se non lo capisce con una semplice discussione, c'è sempre anche la strada difficile: invece di lasciarli scrivere un nuovo codice, farli lavorare su un codice esistente. Se possibile, dovresti trovarli in due diverse aree di lavoro: una con commenti utili adeguati e un'altra priva di commenti. Dover leggere il codice non commentato e non commentato di qualcun altro è una rivelazione per il tuo lavoro.

Ci siamo stati tutti una volta ed eravamo arrabbiati per l'autore originale di qualche fonte per lavorare così sciatto. È la riflessione aggiuntiva che ognuno di noi è anche un tale autore che ti fa capire che dovresti preoccuparti della leggibilità - quindi, non dimenticare di discutere i risultati con il tuo collega in seguito per promuovere questa riflessione.

Se hai un dipendente che non è in grado di seguire le istruzioni, rimproveralo e assicurati che sia chiaro che non aiuterà l'avanzamento della sua carriera. La coerenza nello stile di codifica è fondamentale per un team e se tutti gli altri scrivono commenti e questo non lo è, ciò danneggerebbe lo stile di codifica.

Detto questo, probabilmente puoi aiutarlo. Nella mia esperienza, quando qualcuno protesta che commentare richiede troppo tempo c'è una barriera psicologica come ...

1. È consapevole delle sue scelte di codice / design e non vuole metterle in prosa. (Le revisioni del codice possono essere utili per rafforzare la fiducia in se stessi tanto quanto per abbatterle.)
2. Lavora in modo molto lineare e non pensa molto al futuro. Commentare è doloroso perché lo costringe a scaricare il codice immediato che stava per scrivere dalla sua memoria di lavoro per comporre le sue intenzioni in modo diverso. (Se questo è vero, i commenti diventano molto importanti per la sua qualità del codice.)
3. Storicamente le persone non capiscono i suoi commenti.

È importante per un programmatore rendersi conto che i commenti sono come dei test: non sono solo per un uso futuro - Sono per il programmatore stesso. Lo costringono a pensare diversamente al suo approccio.

Niente di tutto questo è un sostituto di CI, test o revisioni del codice. È solo una delle molte parti critiche della codifica che, di per sé, non sta scrivendo codice.

Ottieni il software di revisione del codice e utilizzalo bene.

Usiamo il forno e lo adoriamo. Abbiamo una politica secondo cui ogni gruppo di modifiche deve essere rivisto (anche se consentiamo agli sviluppatori di raccogliere / approvare le recensioni su tag e fusioni senza conflitti (sebbene la maggior parte di noi utilizzi rebaseif); in questo modo possiamo individuare rapidamente i cambiamenti senza recensioni).

Il codice non chiaro è la ragione per cui una revisione del codice deve essere respinta. Non importa se la correzione è costituita da commenti o codice più chiaro, ma il revisore deve essere in grado di capirla. Alcuni sviluppatori preferiscono riscrivere il codice, ma altri (me compreso) spesso trovano più facile esprimere l'intenzione nei commenti (il codice può mostrare facilmente cosa fa, ma è più difficile mostrare cosa dovrebbe fare).

In caso di dubbi sulla chiarezza del codice, il revisore vince sempre. Naturalmente l'autore lo capisce, perché lo hanno scritto. Deve essere chiaro per un'altra persona.

Utilizzando software come Kiln, nessun changeset viene trascurato. Tutti nel mio team di sviluppo lo preferiscono molto in questo modo. Il software di revisione del codice ha avuto un impatto enorme sulla qualità del nostro codice e sulla qualità delle applicazioni :-)

È facile per gli sviluppatori diventare difensivi con le recensioni rifiutate quando introducono il software per la prima volta, ma nella mia esperienza, non ci vuole molto a capire che le cose vanno meglio in questo modo e abbracciarlo :-)

Modifica: Vale anche la pena notare, proviamo a non far spiegare agli sviluppatori il codice criptico verbalmente o nei commenti nella recensione. Se qualcosa non è chiaro, il posto migliore per spiegarlo è nel codice (nei commenti o tramite refactoring), quindi aggiungi i nuovi changeset alla stessa recensione.

È interessante notare che la leggibilità applicata al linguaggio naturale è misurata dalla velocità di lettura e comprensione. Immagino che una semplice regola possa essere effettivamente adottata, se un particolare commento di codice non migliora questa proprietà, può essere evitato .

Perché commenti

Sebbene il commento al codice sia una forma di documentazione incorporata, esistono diversi modi nei linguaggi di programmazione di fascia alta per evitare la superflua programmazione "sovra-documentata" (di codice significativo) utilizzando elementi del linguaggio stesso. È anche una cattiva idea trasformare il codice in elenchi dal libro di testo di programmazione, in cui le singole dichiarazioni sono letteralmente spiegate in modo quasi tautologico (tenere presente l'esempio "/ * incremento i di 1 * /" nelle risposte già fornite), rendendo pertinenti tali commenti solo ai programmatori inesperti con la lingua.

Nondimeno, è intenzione di provare a commentare il codice "sotto documentato" (ma insignificante) che è veramente "la fonte di tutti i mali". L'esistenza stessa di codice "sotto documentato" è un segnale negativo - o è un disastro non strutturato, o un bizzarro hack di mistico scopo perduto. Ovviamente, il valore di tale codice è almeno discutibile. Sfortunatamente ci sono sempre esempi, quando è davvero meglio introdurre un commento in una sezione di righe di codice formattate (raggruppate visivamente) piuttosto che avvolgerlo in una nuova subroutine (attenzione alla "consistenza insensata" che "è il folletto delle piccole menti") .

Leggibilità del codice! = Commenti sul codice

Il codice leggibile non richiede annotazioni per commenti. In ogni particolare posizione nel codice c'è sempre un contesto di un'attività che questo particolare codice dovrebbe raggiungere. Se manca lo scopo e / o il codice fa qualcosa di misterioso = evitarlo a tutti i costi. Non consentire a strani hack di popolare il tuo codice: è il risultato diretto della combinazione di tecnologie difettose con mancanza di tempo / interesse per comprendere le basi. Evita il codice mistico nel tuo progetto!

D'altro canto, il programma Readable = codice + documentazione può contenere più sezioni legittime di commenti, ad esempio per facilitare la generazione di documentazione "commenti all'API".

Seguire gli standard di stile del codice

Abbastanza divertente la domanda non riguarda il motivo per cui commentare il codice, si tratta del lavoro di gruppo - come produrre codice in stile altamente sincronizzato (che tutti gli altri possono leggere / comprendere). Stai seguendo standard di stile di codice nella tua azienda? Il suo scopo principale è quello di evitare di scrivere codice che richiede refactoring, è troppo "personale" e "soggettivamente" ambiguo. Quindi immagino che se si vede la necessità di usare lo stile del codice, ci sono molti seri strumenti per implementarlo correttamente - a cominciare dall'educazione delle persone e finendo con l'automazione per il controllo di qualità del codice (numerosi lint, ecc.) E (revisione controllo integrato) sistemi di revisione del codice.

Diventa un evangelista della leggibilità del codice

Se si accetta che il codice viene letto più spesso di quanto non sia scritto. Se una chiara espressione di idee e pensieri è chiaramente importante per te, indipendentemente dalla lingua utilizzata per comunicare (matematica, codice macchina o inglese antico) .. Se la tua missione è sradicare il modo noioso e brutto di pensare in modo alternativo .. (scusate , l'ultimo viene da un altro "manifest") .. fai domande, avvia discussioni, inizia a diffondere libri stimolanti sulla pulizia del codice (probabilmente non solo qualcosa di simile ai modelli di design di Beck, ma più simile a quello già menzionato da RC Martin ) che affronta l'ambiguità in programmazione. Segue un passaggio puntuale di idee chiave (citato dal libro di O'Reilly sulla leggibilità)

• Semplifica la denominazione, i commenti e la formattazione con suggerimenti che si applicano a ogni riga di codice
• Affina i cicli, la logica e le variabili del tuo programma per ridurre la complessità e la confusione
• Attacca i problemi a livello di funzione, come riorganizzare blocchi di codice per eseguire un'attività alla volta
• Scrivi un codice di prova efficace che sia accurato e conciso, oltre che leggibile

Eliminando i "commenti", ne rimane ancora molto (immagino che scrivere codice che non abbia bisogno di commenti sia un ottimo esercizio!). La denominazione di identificatori semanticamente significativi è un buon inizio. Successivamente, strutturando il codice raggruppando le operazioni connesse logicamente in funzioni e classi. E così via. Un programmatore migliore è uno scrittore migliore (ovviamente, assumendo altre abilità tecniche fornite).

mi sbaglio a concentrarmi sui commenti del codice o è indicativo di un problema più grande che dovrebbe essere affrontato?

Un po '. Il grande codice non ha bisogno di commenti. Tuttavia, come hai detto, il suo codice non è auto-documentante. Quindi non mi concentrerei sui commenti. Dovresti concentrarti sul miglioramento delle abilità e della maestria dei tuoi sviluppatori.

Quindi come farlo? I suggerimenti di Doc Brown su revisioni / sessioni di refactoring sono una buona idea. Trovo che la programmazione in coppia sia ancora più efficace, ma potrebbe anche essere molto più difficile da implementare.

Prima di tutto, suggerirei di ricollegare il tuo approccio ai commenti.

Se sono commenti di documentazione a livello di API (esposti in seguito al pubblico), questo sviluppatore semplicemente non sta facendo il suo lavoro. Ma per tutti gli altri commenti, fai attenzione.

Nella maggior parte dei casi li incontro, i commenti sono malvagi. Consiglierei di leggere il capitolo dei commenti sul codice di "Clean code" di Robert Martin per capire bene perché.

I commenti danneggiano il tuo codice in diversi modi:

1) Sono difficili da mantenere. Dovrai fare un lavoro extra durante il refactoring; se si modifica la logica descritta nel commento, è necessario modificare anche il commento.

2) Mentono spesso. Non puoi fidarti dei commenti e devi invece leggere il codice. Il che solleva la domanda: perché dovresti aver bisogno dei commenti?

// this method returns the sum of 'a' and 'b'
public int GetHash(int a, int b)
{
    //the calculation of the hash
    int result = a*b;
}

(L'hash non è la somma ma il prodotto.)

3) I commenti ingombrano il codice e molto raramente aggiungono alcun valore.

La mia soluzione: invece di aggiungere altri commenti, prova a sbarazzartene!

Se un membro del team ha difficoltà a comprendere il codice di un altro membro del team (per qualsiasi motivo); quindi quel membro del team dovrebbe essere in grado di scoprire chi ha scritto il codice originale (qualsiasi sistema di controllo di revisione sano di mente) e dovrebbe essere incoraggiato a chiedere all'autore del codice di spiegarlo direttamente (ad esempio, avvicinarsi alla propria scrivania, sedersi e discuterne).

In questo caso, se la mancanza di commenti è un problema, la persona che non sta commentando adeguatamente il proprio codice trascorrerà gran parte del proprio tempo a spiegare cosa ha fatto; e (se sono intelligenti) inizieranno ad aggiungere commenti per evitare di perdere tempo con tutte quelle spiegazioni.

Si noti che incoraggiare i membri del team a chiedersi spiegazioni è utile per altri motivi. Ad esempio, forse un membro del team è meno esperto e può imparare le cose dai membri del team più esperti.

Principalmente, incoraggiando i membri del team a chiedersi reciprocamente spiegazioni, si crea un sistema di auto-bilanciamento; dove diversi membri del team "si adattano automaticamente" tra loro.

Questa è in gran parte un'estensione della risposta di tdammer, ma esegue revisioni del codice a intervalli regolari.

Il fatto che lui (e altri sviluppatori) si siedano, esaminino il loro codice e più o meno difendano davanti ai loro superiori e colleghi renderà tutti programmatori migliori e aggiungerà valore reale in un periodo di tempo relativamente breve. A breve termine, non fornirà allo sviluppatore in questione alcuna scusa per commentare correttamente il suo codice al momento della revisione.

EDIT: Non sono sicuro del motivo per cui qualcuno dovrebbe sottovalutare il mio suggerimento - forse ho dato per scontato che i benefici della revisione del codice sarebbero conoscenze comuni ... si prega di vedere questo thread come un'analisi della comunità della pratica:

La revisione del codice è una buona pratica?

Considerando le opinioni spesso estreme sui commenti, esito a ponderare. Detto questo ...

Quali sono alcuni argomenti che posso presentare per scrivere un codice (illeggibile) che dovrebbe essere adeguatamente documentato?

Capire come scrivere codice gestibile e leggibile richiede tempo, pratica ed esperienza. I programmatori inesperti (e purtroppo molti esperti) spesso soffrono dell'effetto Ikea ( PDF ). Questo perché l'hanno costruito e lo conoscono intimamente, e sono sicuri che il codice non sia solo eccezionale, ma anche leggibile.

Se la persona è un grande programmatore, allora poca documentazione è necessaria. Tuttavia, la maggior parte dei programmatori non è eccezionale e molto del loro codice soffrirà nel reparto "leggibilità". Chiedere al programmatore mediocre o in via di sviluppo di "spiegare il proprio codice" è utile in quanto li costringe a visualizzare il proprio codice con un occhio più critico.

Questo significa "documentare" il loro codice? Non necessariamente. Caso in questione, ho avuto un programmatore simile con questo problema in passato. L'ho costretto a documentare. Sfortunatamente la sua documentazione era indecifrabile come il suo codice e non ha aggiunto nulla. In retrospettiva le recensioni sui codici sarebbero state più utili.

Tu (o un delegato) dovresti sederti con questo programmatore e recuperare un po 'del suo vecchio codice. Non le nuove cose che conosce solo lavorando su di esso. Dovresti chiedergli di guidarti attraverso il suo codice con una minima interazione. Questa potrebbe anche essere una sessione di "documentazione" separata, in cui deve spiegare per iscritto il suo codice. Quindi dovrebbe ricevere feedback su approcci migliori.

A parte questo ... a volte è necessaria della documentazione indipendentemente da quanto sia buona la "leggibilità" del codice. Le API dovrebbero avere documentazione, operazioni estremamente tecniche e complesse dovrebbero avere documentazione per aiutare il programmatore a comprendere i processi coinvolti (spesso al di fuori del dominio di conoscenza dei programmatori), e alcune cose come le regex complesse dovrebbero davvero documentare ciò a cui stai confrontando.

Molti progetti richiedono la documentazione del codice: documento di interfaccia, documento di progettazione, ...

Alcuni progetti richiedono che tale documentazione sia inserita nei commenti del codice ed estratta con strumenti come Doxygen o Sphinx o Javadoc, in modo che il codice e la documentazione siano più coerenti.

In questo modo, gli sviluppatori sono tenuti a scrivere commenti utili in codice e questo compito è integrato nella pianificazione del progetto.

Dichiarerò ciò che la maggior parte delle risposte e dei commenti suggeriscono: probabilmente dovrai capire il vero problema qui piuttosto che cercare di far passare la tua soluzione percepita.

Sei motivato a vedere i commenti nel suo codice; perchè ? Hai dato una ragione; perché questa ragione è così importante per te? Invece è più motivato a fare qualcos'altro; perchè ? Darà una ragione; perché questa ragione è così importante per lui? Ripeti fino a quando non arrivi al livello in cui sorge realmente il conflitto, e cerca di trovare una soluzione con cui entrambi puoi convivere. Scommetto che ha ben poco a che fare con i commenti.

Se segui un buon standard di codifica, sarà richiesto un numero minimo di commenti. le convenzioni di denominazione sono importanti. I nomi dei metodi e i nomi delle variabili dovrebbero descriverne il ruolo.

Il mio TL mi suggerisce di usare meno commenti. vuole che il mio codice sia comprensibile e auto-descrittivo. semplice esempio: nome della variabile per il tipo di stringa utilizzato per il modello di ricerca

   var str1:String="" //not uderstandable
   var strSearchPattern:String="" //uderstandable

Adoro le risposte alla recensione del codice, ma forse anche il mio processo sarà di aiuto.

Adoro i commenti, ma non li aggiungo quasi mai al codice al primo passaggio. Forse è solo il mio stile, ma colpirò la stessa sezione di codice da 3 a 5 volte durante lo sviluppo (refactoring, test di scrittura, ecc.).

Ogni volta che mi confondo leggermente o ogni volta che qualcuno mi fa una domanda su una sezione di codice, cerco di risolverlo in modo che abbia senso.

Questo può essere semplice come aggiungere un commento rimuovendo un insieme confuso di operazioni nella propria funzione o può innescare un refactor più grande come l'estrazione di un nuovo oggetto.

Ti suggerisco di incoraggiare tutti i membri del gruppo a "possedere" che il loro codice sia leggibile da altri - questo significa che ogni volta che qualcuno ti pone una domanda sul tuo codice, ti impegni a fare una modifica - o meglio ancora abbinalo a quello persona per apportare la modifica subito!

Prendi seriamente in considerazione l'idea di farne parte come parte del tuo "Contratto di gruppo" (E di creare definitivamente un contratto se non ne hai uno) - in questo modo tutti lo hanno concordato e lo hai appeso a un muro da qualche parte in modo che non ci sia ' t qualsiasi domanda su cosa hai accettato di fare.

Forse questo ragazzo ha bisogno di apprezzare la buona disciplina di programmazione e perché è importante che altre persone siano in grado di capire il codice che ha scritto.

Ho lavorato su alcune basi di codice davvero terribili nella mia carriera, quelle in cui il codice era così mal organizzato, i nomi delle variabili erano così poveri, i commenti così cattivi o inesistenti, che la base di codice ha danneggiato la mia produttività. Non puoi lavorare per correggere o migliorare una base di codice che non capisci, e se è scritto in modo impenetrabile per i nuovi arrivati, passeranno più tempo a cercare di capirlo che a lavorarci davvero.

Non c'è insegnante migliore dell'esperienza dura!

Ogni base di codice ha alcuni bit orribili in agguato, parti del sistema che nessuno vuole toccare perché hanno paura di rompere qualcosa o non possono fare alcun lavoro significativo perché chi ha scritto il codice è partito da tempo e ha preso la sua comprensione del codice con loro. Se quel codice non è commentato e non si documenta da sé, non fa che peggiorare le cose.

Ti suggerisco di trovare la parte della tua base di codice che è così, e di dargli la responsabilità del tuo fastidioso programmatore. Dagli la proprietà di esso, fagli la sua responsabilità, fagli imparare il vero dolore di lavorare su un codice che non può essere mantenuto perché non è ben documentato o impossibile da capire in un breve lasso di tempo. Dopo qualche mese di lavoro, sono sicuro che inizierà a venire in giro.

Dagli un altro codice senza commenti e chiedigli di capire il codice. Forse capirà l'importanza di commenti adeguati allora.

Questo programmatore esegue un po 'di manutenzione del codice? In caso contrario, dovrebbe: verificare la presenza di eventuali progetti che non ti piacciono e assegnargli la manutenzione.

Di solito quelli sono i progetti mal documentati in cui perdi ore a cercare di capire cosa sta succedendo per correggere ciò che avrebbe potuto essere facile da correggere. Se questo tipo di esperienza non lo fa desiderare aggiornato, la documentazione corretta e utile nulla lo farà.

In uno dei miei progetti precedenti mancavano dozzine di commenti (algoritmo, risultati o alcuni JavaDoc di base), quindi ho appena deciso di fare 130 problemi per lui, e-mail di notifica su ogni problema ogni 4 giorni. Dopo 3 settimane ha avuto 280 problemi, quindi ha deciso di scrivere commenti.

I commenti hanno uno scopo e uno solo:

Perché questo codice fa questa cosa?

Se un commento non spiega perché qualcosa è come è, allora dovrebbe essere rimosso. I commenti inutili che ingombrano il codice sono meno che inutili, sono attivamente dannosi.

Ho l'abitudine di rendere i miei commenti la cosa più ovvia nel mio IDE. Sono evidenziati con testo bianco su sfondo verde. Attira davvero la tua attenzione.

Questo perché il codice spiega cosa sta facendo qualcosa e i commenti sono per il motivo per cui lo sta facendo. Non posso sottolinearlo abbastanza.

Un buon esempio di commento:

/* Must instantiate clsUser before trying to encrypt a password because the code to 
   encrypt passwords only uses strong encryption if that module is loaded. */

Un cattivo esempio:

/* instantiate clsUser */

Se stai usando i commenti come "sezioni" di codice: taglia il tuo metodo mammut in funzioni più piccole e utili e rimuovi i commenti.

Se stai dicendo quello che stai facendo nella riga successiva: Rendi il codice autoesplicativo e rimuovi il commento.

Se stai usando commenti come messaggi di avviso: assicurati di dire perché.

Per integrare le risposte qui, potrei aggiungere "Se vuoi farlo nel modo giusto devi farlo da solo."

Non intendo diventare "commentatore principale di codice", intendo diventare un modello di ruolo nel dimostrare ciò che vorresti che facesse questo altro sviluppatore. Dicono che mostrare è più efficace del raccontare . Se riesci a dimostrare il vantaggio di commenti di qualità, o anche fare da mentore a questo altro sviluppatore (nella misura in cui è disposto), potresti trovare più successo nell'adozione dei commenti in codice.

Allo stesso modo, a casa ci sono alcune faccende domestiche che non mi interessa fare. Tuttavia quelle stesse faccende sono le faccende di "pet peeve" di mia moglie ... faccende che devono essere fatte per essere felice. La stessa situazione si applica viceversa. Penso che potresti dover accettare che questo altro sviluppatore abbia priorità diverse da te e che non sarai d'accordo con te su tutto. La soluzione che io e mia moglie abbiamo trovato è che per quelle faccende da "pipì da compagnia" non ci resta che fare da soli, anche se ciò significa fare un po 'più di lavoro da soli.

Semplice: se il dipendente non fa commenti, digli di premere shift+alt+jper il commento automatico in ciascun metodo contemporaneamente all'inserimento del codice. eseguire la revisione del codice per evitare questi problemi.