Il "commento divertente" è una cattiva pratica o no? [chiuso]

37

Voglio chiederti se l'aggiunta di alcune "uova di Pasqua" nella documentazione di origine non è professionale o meno. Probabilmente avete letto lo StackOverflow sondaggio per commenti divertenti in una documentazione di fonte, e ho personalmente inciampato in molte di queste cose durante il mio lavoro, compreso divertente (o meno) roba nella documentazione API pubblica (ad esempio questo debole BZZZTT !! 1! Cosa nella documentazione pubblica di Android, posso fornire almeno una dozzina di altri esempi).

Non posso arrivare a un'opinione finale per me stesso, perché ho argomenti contraddittori da solo.

Argomento pro:

Può rallegrare qualcuno e rendere la sua giornata più divertente / produttiva. La maggior parte del codice sorgente non ha bisogno di essere commentata comunque (se il progetto è fatto correttamente), perché il metodo specifico (per esempio) è autoesplicativo, o se è un mucchio di strano codice schifoso, non può essere spiegato in modo significativo, quindi uno scherzo divertente non danneggia le possibili informazioni che puoi ottenere dal documento.

Contro:

Se sei molto concentrato / frustrato, l'ultima cosa di cui hai bisogno è lo stupido scherzo di qualcuno, invece di darti le informazioni di cui hai bisogno sulla porzione di codice documentata, può solo renderti ancora più frustrato. E l'idea di come sarebbe la documentazione se tutti iniziassero a farlo è orribile. Inoltre il tizio che scrive la battuta potrebbe essere l'unico a pensare che sia divertente / interessante / vale la pena perdere tempo a leggerlo.

Cosa pensi?

source-code

— qualcuno
fonte

Si prega di leggere le FAQ e le linee guida del sito per porre domande. Questa domanda in realtà non soddisfa queste linee guida.

— Walter,

8

@Walter: è praticamente la stessa domanda di programmers.stackexchange.com/questions/50928/… , ma per commenti divertenti anziché commenti volgari e la domanda collegata non è chiusa, posta un mese fa. Non perderò tempo a discutere con te che questa domanda soddisfa le FAQ e che è correlata alle migliori (buone) pratiche durante la scrittura del codice.

— Qualcuno il

2

7 voti, questa Q è chiaramente desiderata. Personalmente non so perché sono stato incazzato dalla "truffa" che hai citato molte volte, ma posso vedere gli argomenti per "pro", quindi sono curioso di sapere quale sia il risultato. (Il peggio che ho incontrato a proposito era un programmatore che pensava che una foto "esilarante" di una pistola BB che puntava un gattino con le zampe su doveva essere sulla home page di tutti i nostri server di sviluppo. Sospiro ...)

— James

@sombody - Hai ragione, ma i commenti divertenti non hanno la stessa probabilità di farti licenziare o peggio, a causa di una causa di molestie. Prenderò in considerazione la chiusura dell'altra domanda (non sono sicuro di avere quel diritto quando è stato pubblicato.).

— JeffO,

1

Sono d'accordo che questo post dovrebbe essere riaperto, anche se non posso votare perché non ho il rappresentante. Lo scopo di separare i programmatori da SO è per domande come questa. Inoltre con 22 voti per questa domanda, è chiaramente voluto dalla comunità.

— RoboShop

12

Penso che commenti divertenti facciano perdere tempo: tempo perso a scrivere, tempo perso a leggere, tempo perso a mostrare ai tuoi colleghi l'osservazione divertente che (quasi sempre) è semplicemente sconcertante e così via.

Ma ... nessuno lavora al 100% tutto il giorno tutti i giorni (siti come questo sarebbero vuoti se lo facessimo) e l'umorismo genuino interrompe la giornata e aiuta a mantenere il morale.

Vorrei ancora votare contro semplicemente perché ogni commento 'divertente' che abbia mai letto potrebbe essere stato divertente in quel momento - ma devo ancora vederne uno che in realtà è divertente, la maggior parte sono semplicemente sconcertanti o sono un profondo -scherzo.

Se commenti divertenti fossero davvero divertenti, cambierebbe idea. Ma una volta incoraggiate le battute, incoraggiate imprecazioni o insulti o maliziosità?

— amelvin
fonte

5

+1 Leggi quei commenti solo quando devi correggere qualcosa e non hanno alcun senso allora e quando correggi i bug non sei certo dell'umore di vedere una "battuta intelligente" di qualche altro sviluppatore sull'argomento. Invece di passare il tempo a pensare a uno scherzo, per favore, dedica un po 'di tempo a un codice più chiaro, correggi un bug, ecc. Inoltre, cosa succede con lo "scherzo" se qualcosa viene refactored?

— Jan_V

2

Quindi è proprio come l'umorismo nello spazio della carne: è meglio che sia divertente e che non sia TUTTO ciò che fai.

— Dan Ray,

1

+1 intelligente, purché non faccia male. Mettere stop() //hammertimein ogni istanza di stop non è divertente.

— glasnt,

@glasnt - questo è un commento davvero divertente - ma sarebbe irritante per l'iterazione 2, e successivamente sempre più irritato!

— amelvin,

Consentire l'umorismo nei commenti è perfettamente accettabile. Perché rendere un'industria già asciutta secca e senza umore? Consentire parolacce, insulti o maliziosità è una questione completamente diversa. La mia esperienza è stata totalmente diversa dalla tua. Ho ridacchiato molte volte leggendo commenti informativi che mostravano un arguto senso dell'umorismo. Ha reso la mia giornata migliore. Ci vuole un po 'di intelligenza per essere di buon gusto nel proprio umorismo, ma se può essere fatto con maturità, portalo avanti.

— JBeck,

71

Sono un grande fan di commenti divertenti .

Dovresti essere sempre professionale nei tuoi commenti, ma un po 'di umorismo non ucciderà il lettore.

Soprattutto se il lettore è un membro della tua squadra.

Quello che non mi piace di più, sono gli sviluppatori che si prendono troppo sul serio. Penso che dovremmo divertirci al lavoro, o il lavoro non ne vale la pena.

9

+1 per "Professionale ma divertente"

— deworde

La programmazione è di per sé divertente :)

— Gopi

2

@Sri Kumar: Sfortunatamente, non sempre. :(

— Bobby

1

@Bobby: prendi la decisione di renderlo divertente allora! Se non ti lasceranno andare, porta la tua felicità in un'azienda che se lo merita.

3

+1 per non prenderti troppo sul serio.

— JeffO,

8

Se ha un significato, va bene essere divertenti. Spiegare qualcosa in un commento in modo divertente va bene. Tuttavia, se è solo qualcosa di divertente e non contiene alcun valore reale come commento, è solo fastidioso. Tenere sempre presente che il motivo dei commenti è rendere la manutenzione più efficiente. L'umorismo non deve essere in conflitto con quello, ma se non potesse farlo in modo appropriato.

— Brian Knoblauch
fonte

C'è un commento nel codice di gestione degli errori di un programma critico: "La vita è una _ e poi muori". alla fine della spiegazione. È divertente e ha senso.

— Michael K,

1

@Michael - Questo è un esempio perfetto di quello che penso sia uno spreco. Non è divertente (essendo l'ennesima ripetizione di un'affermazione molto vecchia e stanca) e non aggiunge nulla di valore.

— Brian Knoblauch,

8

Il codice è pensato per la lettura ... molte volte.

Quante battute sai che sono divertenti dopo il centesimo racconto?

@ Thorbjørn Ravn Andersen: che dire dei cartoni animati Dilbert che stampi e appunti sulla parete del tuo cubicolo? ;)

@Pierre, se trovi un singolo Dilbert adatto a inserire un commento sul codice sorgente, per favore fatemelo sapere.

@ Thorbjørn Ravn Andersen: non Dilbert, ma questo meritava lo spazio necessario: i.imgur.com/tu7Fd.jpg

@Pierre, in realtà considero la formulazione in quel poster oltre il limite e non divertente, ma questa è un'altra questione. Quanti ne hai di più?

@ Thorbjørn Ravn Andersen: è l'unico

7

I commenti divertenti sono fantastici.

Dà un'atmosfera positiva al tuo codice apparentemente noioso.
Se ottieni i tuoi tempi in modo corretto, spiega molto meglio di un normale commento noioso. Per "tempismo" qui intendo la pertinenza al codice sotto il commento.
Il tuo codice sarà ricordato da molti, perché alle emozioni viene assegnato un posto migliore nella memoria (umana). Questo è un grande trucco se vuoi che più ragazzi lavorino con te su un progetto open source.
Generalmente utile nelle recensioni. Rende il tuo codice molto più sopportabile. Ovviamente dovresti prima concentrarti sulla scrittura di un buon codice. Sento che quando si è sicuri del codice che scrivono, i commenti divertenti sono solo un effetto collaterale.

Basta non essere divertente come questo ragazzo ;)

— Reno
fonte

6

Eccone uno che ho scritto alle due del mattino ("DQ" è la sigla della mia azienda):

// Twas the night before go-live and all through DQ
// the devs were all crying and yes, this means you.
// Keys had been saved with both hyphens and 'scores
// which left this programmer with finger pad sores.
// The solution I crafted, you'll likely find lacking:
// to OR them together with judicuous hacking.

$hyphenated = str_replace('_','-',$data_type_key);
$underscored = str_replace('-','_',$data_type_key);
// (and then see line 46)

— Dan Ray
fonte

3

Sì, è probabile che cose del genere si verifichino alle 2 del mattino, ma non credo che sia una buona battuta: qualcuno dopo aver letto 6 righe di testo se vuole vedere il commento per 2 righe di fonte. La stessa proporzione di dover leggere 600 righe di saggio che spiega 200 righe di codice

— qualcuno

5

Oh, l'efficienza era fuori dalla finestra. Questo progetto era già un tale ammasso-sai-cosa, un po 'di leggerezza ha fatto molta strada verso il morale delle 2 del mattino. Se noti, il codice che sto scrivendo qui è quello di aggirare la sciattezza di qualcun altro, che era praticamente ciò di cui parlavano le ultime due settimane della marcia della morte. Non perdono questo genere di cose come una pratica normale, ma confesso di essere abbastanza soddisfatto di questo.

— Dan Ray,

In quella situazione sarei anche abbastanza contento

— qualcuno il

Non inserire numeri di riga, usa "cerca <qualunque>" invece dove <qualunque> è esso stesso un commento.

— Vinko Vrsalovic,

3

Se stavi rivedendo il codice sorgente di fronte al cliente ti vergogneresti?

Nessuna delle risposte attuali sembra tenerne conto. Alcuni clienti non hanno alcun senso dell'umorismo e prenderanno le battute come un indicatore del fatto che non prendi sul serio il tuo lavoro. Ne dedurranno che sei incurante del tuo lavoro.

I commenti con codici divertenti a volte possono essere poco professionali e inappropriati.

— M. Dudley
fonte

3

Al di là di ciò che è già stato detto, se stai lavorando in un team internazionale, alcuni dei tuoi colleghi stranieri potrebbero non prendere la battuta, perché o di alcuni riferimenti culturali locali o di un gioco di parole che non è compreso da qualcuno per cui l'inglese non è madrelingua . La stessa cosa vale per i progetti open source.

— Vartec
fonte

2

Se è efficiente e non fa perdere tempo ai lettori (in lettura o comprensione), allora non vedo un problema con un po 'di umorismo.

— jonners99
fonte

2

Proprio come gli scherzi nel mondo reale, se li fai continuamente non è divertente, non produttivo e non professionale. Ma c'è un tempo e un luogo per tutte le battute, e c'è un tempo e un posto nel codice. Proprio come nel mondo reale, è sapere dove, quando e come fare la battuta.

— James Bedford
fonte

1

Dipende, per gli incarichi al college, facevo quasi sempre commenti divertenti, poiché sapevo che non sarebbe mai stato usato ed è solo un compito a casa.

Per progetti più seri, li userei ancora qua e là, ma non così diffusi, quindi è fastidioso o difficile da capire, sfidando lo scopo del commento.

Ricordo di aver fatto un po 'di programmazione Web, dove ho dovuto evitare incompatibilità con i browser e strani problemi tecnici. A volte finiva con commenti pieni di rabbia e odio nei .jsfile.

La mia regola empirica di base è: se è in qualche modo ovvio ciò che fa la sezione del codice, COMMENTI DIVERTENTI ACCENDERE!

Se il codice è così oscuro e offuscato da morire (come la " classe inline "), è meglio che utilizzi i commenti che mi capirò tra un paio di giorni ...

— Polemone
fonte