Trattare con volgarità nel codice sorgente [chiuso]

In che modo le persone trattano con volgarità nel codice sorgente e nei commenti VCS. Conservare o eliminare?

Che dire di soft-expletives come WTF o Arrgggh?

Non professionale, offensivo o qualcosa da scrollare di dosso?

Dovrebbe essere delicatamente scoraggiato

..non puoi sapere chi vedrà il codice sorgente nel corso della sua 'vita.

Mentre fa tutto parte del lavoro frustrarsi con un pezzo di codice particolarmente complesso o vecchio e vuoi parlarne, inserire nel codice sorgente espletivi / rant / arte ASCII / barzellette sbagliate / osservazioni offensive non è professionale cattiva idea nella mia esperienza. A volte, l'ingegnere che scrive i commenti è ignaro degli eventuali effetti che i suoi commenti potrebbero avere - ecco alcuni dei problemi che ho riscontrato:

• Un numero elevato di imprecazioni nel codice rilasciato al pubblico come codice open source / di esempio.
• Scherzi di cattivo gusto che causano offese profonde ad alcuni membri del team con conseguente tribunale industriale.
• Osservazioni da buttare via che erano in realtà razzisti / sessisti / di genere causano il licenziamento delle persone.

Mentre tutti abbiamo bisogno di avere alcuni sbocchi per la frustrazione / divertimento / japing, il codice sorgente non è il posto dove farlo, IMO. Non inseriresti imprecazioni / barzellette / commenti offensivi in ​​un contratto, pagine di aiuto, progetti o altri documenti professionali, anche se tali documenti potrebbero essere letti anche meno spesso del codice sorgente.

Se i capisquadra si mettono a dura prova, ci saranno problemi, quindi dico "delicatamente scoraggiato" per mezzo di una parola tranquilla con ingegneri problematici e fornito meccanismi di sfiato adeguati per sfogarsi, che si tratti di Facebook, di messaggistica istantanea , air hockey o un sacco da boxe.

Non è una difesa affermare che i commenti sono stati compilati - che ne pensi di JavaScript o di qualsiasi altro codice dinamico sul lato client?

Ecco alcune delle esperienze del mondo reale che ho avuto che hanno plasmato la mia opinione:

• Mentre lavoravo in Microsoft, ho notato che un ingegnere del software non conosceva l'ortografia corretta di "impossibile" - gli mancava la o, la - e aveva scritto gran parte del suo codice con lunghe spiegazioni di come non poteva far funzionare X perché Y stava causando il problema Z. Il suo codice era eccezionale; la sua ortografia non era così buona. Basti dire che ogni successivo revisore di questo codice (ad esempio me) è stato allarmato nel vedere un gran numero di imprecazioni casuali nel codice. Parte di questo codice è stata mostrata ai partner (autori dei driver). Immagina il loro orrore nel vedere le imprecazioni. Idealmente, gli sfoghi dovrebbero essere stati al project manager in forma verbale (nel qual caso la persona Y può essere coinvolta nella discussione) o forse impegnare messaggi, ma non nella fonte.

• In una società, un individuo di lingua straniera si è unito a una squadra prevalentemente di lingua inglese. Ha scritto commenti nella sua lingua, pensando che nessun altro potesse leggerli. Questo andava bene, fino a quando Babelfish / Google Translate non hanno rilasciato un'opzione "in inglese" per la sua lingua, a quel punto il resto del team ha tradotto alcuni commenti e si è spaventato per i commenti sporchi e spesso sprezzanti che il ragazzo stava facendo sull'azienda , la sua squadra e una collega di sesso femminile. Imbarazzante .

• In un'altra società, un ragazzo è stato davvero preso con l'arte ASCII e ha inserito ogni sorta di arte nel suo codice sorgente, non individuato (o forse benedetto) dai revisori del codice. Dopo un po 'si soffermò sui draghi, per qualche motivo, di solito con una specie di tag line. Più tardi, una persona gallese si unì alla squadra. L'emblema nazionale del Galles è un drago rosso, quindi il nuovo ragazzo era inizialmente allegro per le immagini, ma poi si è offeso quando alcune delle sciocche linee di tag potevano essere interpretate come offensive. Sì, è richiesta una mediazione da parte del team leader, ma ciò non avrebbe dovuto accadere.

Nomi / dettagli rimossi per proteggere l'innocente.

Se vendi il tuo codice sorgente (ovvero sei uno scrittore di componenti), probabilmente non dovrebbe essere lì.

Se è una questione di prudenza, allora bene, dipende da te.

Se vedi qualcuno scrivere un sacco di WTF, forse è un segno che dovresti parlare con loro dei problemi che stanno avendo.

Se qualcuno sta indirizzando la propria aggressività verso il codice di un'altra persona, potrebbe essere molestare quella persona e hai una situazione completamente diversa da affrontare. Forse hanno un reclamo legittimo e non sanno come esprimerlo correttamente. Forse sono solo un idiota.

Non sarebbe saggio avere solo una sorta di filtro di contenuto, qualunque cosa uno sviluppatore scriva è importante e ti dice molto su come stanno andando le cose.

Lavoro per un'azienda Fortune 500 che progetta, produce e vende prodotti di consumo con controllori µ che eseguono codice sviluppato internamente. Il contenzioso è sempre una possibilità, sia da parte dei consumatori che sperano di arricchirsi rapidamente, sia da parte di concorrenti che rivendicano una violazione. Per questo motivo, scriviamo il nostro codice e TUTTI i commenti con la consapevolezza che potrebbe (probabilmente) rientrare sotto il controllo dei giurati ostili in qualche momento. Ciò significa che i nomi delle variabili e delle funzioni non dovrebbero includere termini incitanti, come KILL_CHILD(int process_id). Mentre lo scopo di questa funzione di esempio potrebbe benissimo essere quello di terminare i processi figlio, come potrebbe una giuria ostile vedere quel nome di funzione se il figlio dell'attore fosse ucciso mentre utilizzava il prodotto?

I commenti nel codice possono essere anche peggiori. Mentre una squadra di difesa decente potrebbe probabilmente gestire spiegando cos'è un processo figlio (dall'esempio precedente) e perché potrebbe essere necessario terminarlo, sarebbe quasi impossibile difendersi da un commento come:

// The following section of code is REALLY BAD!!!  I hope
//  it doesn't burn anybody's house down.

Commenti fuori mano del genere sono stati fattori decisivi in ​​casi giudiziari reali.

Su un argomento correlato, anche i nomi dei progetti possono essere dannosi se sottoposti a un intenso contenzioso. Ricordi il tumulto dei gruppi conservatori a metà degli anni '90, quando fonti di notizie sulla tecnologia riportarono "SATAN Unleashed On The Internet" ?

<rant_mode_off>

Detto questo, per i progetti personali sei libero di fare ciò che ti piace nel tuo codice.

Se ti dà fastidio e tu sei l'onorevole capo, non vedo perché non potresti implementare una regola al riguardo. Voi siete , dopo tutto il leader in questo situazione ipotetica.

Tuttavia, se ti dà fastidio e nessun altro sembra preoccuparti, forse dovresti semplicemente succhiarlo.

Potrei non essere la persona giusta da chiedere dal momento che uso spesso volgarità.

Penso che dipenda principalmente da quanto PC (politicamente corretto) sia il tuo ambiente.

Se scrivo un codice per una società in giacca e cravatta, proverei a non usare affatto volgarità, ma se è per un progetto di hobby o qualcosa che tendo a esprimere la mia mente più liberamente.

Mi sembra che negli Stati Uniti e in alcuni altri paesi le persone siano molto più PC (o bloccate) rispetto ai Paesi Bassi dove vivo e lavoro.

Come bonus aggiuntivo, ecco alcune statistiche sulla volgarità nel codice: http://andrewvos.com/2011/02/21/amount-of-profanity-in-git-commit-messages-per-programming-language/

Sono propenso a concordare sul fatto che può essere abbastanza poco professionale, ma tutti imprecano di tanto in tanto, quindi cerco di non tenerlo contro gli altri. Detto questo, la base di codice tende a riflettere la professionalità complessiva del gruppo, quindi una base di codice esplicativa carica potrebbe riflettere un gruppo non professionale e potrebbe essere necessario un incontro per "applicare un po 'di smalto" al gruppo. Allo stesso modo, se nel codice compaiono determinate tendenze, potrebbe essere un indicatore di problemi generali all'interno del gruppo che devono essere risolti (ad esempio, l'API con cui stai lavorando ha problemi che frustrano gli sviluppatori).

In termini di base di codice, di solito modifico il commento pertinente per essere sicuro per il lavoro e lasciarlo a quello. A seconda della lingua con cui stai lavorando, questa è sempre una buona idea in quanto non sai mai cosa potrebbe apparire di fronte a un cliente o cliente.

È poco professionale, offensivo o qualcosa da scrollare di dosso?

Forse tutti e tre ... a seconda del tuo punto di vista.

È natura umana per le persone esprimersi usando "linguaggio colorato" in determinate situazioni. Più in alcune culture che in altre, e alcune persone più di altre. Ma la tendenza è universale.

Se fossi in te, lo scrollerei di dosso a meno che tu non sia disposto a renderti impopolare con i tuoi compagni di lavoro.

Tuttavia, se il codice sorgente / i commenti VCS vengono pubblicati al di fuori della propria organizzazione, la direzione potrebbe voler prendere una linea più forte, sulla base del fatto che è dannoso per le aziende offendere i propri clienti.

Uno dei problemi con volgarità è che è diverso da cultura a cultura. Negli Stati Uniti, le cose innocenti tendono a essere "cancellate", mentre in altri paesi è possibile ascoltare la stessa lingua scambiata nelle discussioni parlamentari.

Oscenità nel codice e nei commenti di commit è abbastanza comune, probabilmente a causa della vista "nessuno lo vedrà". Penso che in realtà sia più comune ora che la maggior parte delle organizzazioni bandisce le uova di Pasqua.

Personalmente ritengo che le cose non destinate ai clienti (come i materiali di commit interni) non siano un grosso problema.

Tuttavia, la maggior parte delle grandi multinazionali sono gestite da dipartimenti legali e "luoghi di lavoro sicuri" e tutto il resto, il che significa che tutto ciò che potrebbe essere offensivo per almeno una persona è un problema e una potenziale causa di licenziamento. Odio ammetterlo, ma tendo a inchinarmi alle regole di coloro che pagano il mio stipendio.

Una rapida soluzione a questo problema è installare un filtro volgarità sul sistema di controllo del codice sorgente (come script di presubmit o controllo periodico).

Penso che sia ok fintanto che non è fuori controllo come far cadere le bombe laggiù. Ho visto un ragazzo con cui lavoro scrivere una sceneggiatura tra due personaggi che discutono dei vari oggetti che rappresentano ciascuno. C'è stato un commento multilinea che ha funzionato per circa 30 righe di questi due personaggi che parlavano avanti e indietro.

/ * * igor: dovrei farmi un massaggiatore pubblico? * Frankenstein: ah igor, erediterò dai tuoi tratti migliori ... * /

È andato avanti così per molto tempo. Ha creato due oggetti chiamati, avete indovinato: Frankenstein e Igor come parte di un controllo di sanità mentale. In realtà era molto creativo ma una totale perdita di tempo. Avrei preferito vedere alcuni WTF o imprecazioni piuttosto che una sceneggiatura tra due oggetti C # ...

Dipende dalla cultura dell'azienda / cliente. Ad esempio, se stai sviluppando un software biblico, le imprecazioni in qualsiasi forma sono sicuramente sgradite. D'altra parte, uno sviluppatore di giochi potrebbe non preoccuparsi troppo (o andare all'altro estremo).

Sono sempre dell'idea che qualsiasi commento (in codice o commit) dovrebbe essere utile . Alcune parole attirano la nostra attenzione più di altre: le imprecazioni, anche la varietà morbida, sono sicuramente notate. Può essere utile richiamare l'attenzione su qualcosa che è semplicemente sbagliato ma non hai ancora modo di evitarlo.

Detto questo, non uso le imprecazioni ma a volte userò cose come "Doh!" o "Eh?" che non è troppo diverso nello spirito. Se ti dà fastidio, parlane con l'autore del reato - potrebbe non pensarci. Se ti dicono di fare un'escursione e ti senti fortemente a riguardo, vai a chiamare il manager. Se non ricevi supporto dal gestore, dovrai imparare a conviverci o andare altrove.

Bene, non sono esattamente sicuro di cos'altro dovresti dire su questo codice:

tocommit = (n + (COMMITSIZE/PAGESIZE) - 1) & ~(COMMITSIZE/PAGESIZE - 1);

Questo codice è stato estratto da una base di codice reale, estremamente grezza, che ho cercato di ottimizzare ultimamente. (Il codice è open source, quindi non sto rivelando i segreti di alcun datore di lavoro qui o altro.)

Come altri hanno già detto, dipende dal posto di lavoro e da chi vedrà il codice sorgente.

Se vendessi il codice sorgente avrei un secondo repository di sole versioni rilasciate e non consentirei alcun commento di check-in al di fuori di una descrizione di ciò che ciascuna nuova versione fornisce. Cosa faccio ogni giorno e tutti i miei passi falsi sono tra me e il mio team, non i miei clienti.

Attualmente il mio server di build riporta commenti su OMG, WTF, kludge, mess e TODO come metrica della pulizia rimanente per farlo, in questo momento fanno parte del processo.

Se vedi parolacce nei software open source e vuoi sbarazzartene, preparati alla possibilità di push-back. Non limitarti a scrivere un rapporto sui bug di tre righe e aspettati che venga accettato. Scrivi un mini-saggio che spieghi perché la volgarità e il linguaggio discriminatorio sono cattivi e anticipano le confutazioni.

Penso che sia una questione di preferenze personali. Quella roba non mi disturba davvero, quindi probabilmente la lascerei. Potrebbe anche darmi un suggerimento su dove si trovano le aree problematiche nel codice.

Si disturbano a voi ? Dal fatto che stai ponendo questa domanda, immagino che lo facciano. In tal caso, rimuoverli o ripulirli in commenti più appropriati su ciò che è sbagliato.