È una buona pratica commentare con il nome del proprietario? [duplicare]

Per prima cosa, non dovresti mai avere commenti come questo nel tuo codice. Né con il nome dell'autore, né senza. Un nome aiuta, poiché indica chi deve essere incolpato per ignorare le regole più elementari del codice di commento.

Ad esempio il tuo primo esempio è un commento che parla di un bug che viene corretto. Perché una persona che legge il codice si preoccupa di cosa hai risolto e quando? C'era un bug È risolto ora. Quindi non disturbare i lettori sul fatto che il codice fosse bacato in passato.

Un commento in un codice deve aiutare a capire che cosa sta facendo questo codice. Non è ciò che il codice non è riuscito a fare in passato.

Il tuo secondo esempio non è buono neanche. Ci sono strumenti di tracciamento dei bug per questo.

In secondo luogo, ci sono molti motivi per evitare nomi di persone nei commenti.

• I commenti diventano rapidamente obsoleti. Diciamo che sono orgoglioso di un metodo che ho scritto, e voglio davvero mettere il mio nome in un commento, così tutti sapranno che sono questo autore intelligente che ha avuto questa idea geniale. Un mese dopo, il mio collega ha rigettato il metodo . Un mese dopo, un'altra persona lo modifica . Un mese dopo sono licenziato dalla compagnia perché non sapevo come usare i commenti. Il mese successivo, un altro sviluppatore apporta modifiche sostanziali al codice. Eccoci, non c'è più alcuna riga da quello che ho scritto, e il commento dice che sono io quello che ha digitato il codice vero e proprio.

• I commenti non seguono le modifiche in una squadra. Che cosa succede se il codice è stato scritto da Joe, Joe ha lasciato una società dieci anni fa e ora ci sono due nuovi Joe in azienda? Ha senso leggere in un commento che un pezzo di codice è stato scritto da Joe?

• Non duplicare ciò che è già stato fornito dai registri di controllo della versione. Questi registri non sono qui "solo perché lo fanno". Permettono, in qualsiasi momento, di sapere con precisione chi ha fatto cosa e quando.

• I commenti mentono. E potrebbe contenere errori , in generale. Cosa succede se metto il mio nome sul codice di qualcun altro, solo per sbaglio? Almeno un registro di controllo della versione non mente e non ha errori.

• Metti nomi ... per fare cosa? Dai la colpa alle persone per i bug? Sii orgoglioso di il tuo codice? In entrambi i casi, ci sono problemi più seri nell'azienda e le relazioni tra i colleghi da considerare prima di chiedere se i nomi devono essere messi nei commenti o meno. Come parte di un team, contribuisci a una base di codice comune. Se non c'è codice condiviso e tutti stanno lavorando su una parte separata di un codice, allora che senso ha avere un team di sviluppatori?

• Ultimo ma non meno importante, come ho detto prima, l'unico scopo di un commento è quello di aiutare a capire il codice. Conoscere il nome di una persona che ha fatto qualcosa con il codice difficilmente ti dice cosa sta effettivamente facendo il codice.

In uno dei precedenti datori di lavoro, lo stile di commento è composto da:

// 20DEC11. ABC. Bug 126230, Iterator is off by one when reading from networked drives.

Dove ABC è le iniziali dello sviluppatore. Questa azienda ha distribuito software "shrinkwrap" per oltre 17 anni e ha migrato attraverso circa 5 diversi programmi di controllo delle versioni. La cronologia delle versioni di alcuni file si trova nelle centinaia di revisioni, quindi forzare un po 'di ventosa a provare a setacciare le oltre 300 revisioni è una punizione crudele. Il genitore aziendale occasionalmente costringeva la delocalizzazione di alcune parti, quindi la data doveva essere impostata nel (vecchio) modo dell'esercito (con 2 anni di cifre), in modo che non si ricevessero tutti i tipi di numeri strani per il 20 dicembre 2011, come 12/20/2011 o 20/12/2011 .

In alternativa, alcuni assomigliano a:

// 20DEC11. VBS. ABC. Task 126230, Check annual IRS limits for Roth IRA detectability.

Dove VBS significa "verifica prima della spedizione" e rappresenta i numeri magici stabiliti da leggi o regolamenti che devono essere controllati annualmente. Nient'altro può contenere quelle 3 lettere e non devi mai cancellare uno di quei commenti.

Penso che il pattern che potrebbe innescarsi sia una mini-discussione nel file del codice sorgente.

// LRF- We should refactor this code
// John Q Public aka JQP- No, lets defer this until after version 4. 
//                        Don't stir up any mud.
// LRF- Several branches of the if-then logic aren't covered by unit tests
// JQP- Not interesting, they are edge cases not expected in production

Le discussioni nei commenti di codice si evolvono troppo lentamente per essere efficaci: potrebbero passare anni prima che un altro sviluppatore legga i commenti che hai appena scritto. In un mondo meraviglioso ci sarebbe un IDE e controllo del codice di revisione del codice integrato e sistema di discussione con le notifiche alle parti interessate per ogni nuovo commento.

Nel frattempo, dove ci sono ancora negozi che non hanno ancora il controllo del codice sorgente, di tanto in tanto vedrai queste mini discussioni (o l'inizio di esse) nel codice sorgente.