it-swarm.it

Trattare con volgarità nel codice sorgente

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?

34
sal

Dovrebbe essere scoraggiato delicatamente

..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/risentimenti/arte ASCII/barzellette sbagliate/osservazioni offensive è non professionale cattiva idea nella mia esperienza. A volte, l'ingegnere che scrive i commenti ignora gli 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 fanno sì che le persone vengano licenziate.

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/battute/commenti offensivi in ​​un contratto, pagine di aiuto, progetti o altri documenti professionali, anche se tali documenti possono 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 far uscire Steam, 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 aggiunto gran parte del suo codice con lunghe spiegazioni di come impossibile 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 qualsiasi successivo revisore di questo codice (ad es. 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 inviare 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 della squadra ha tradotto alcuni commenti e si è spaventato per i commenti sporchi e spesso dispregiativi che il ragazzo stava facendo sull'azienda , la sua squadra e una collega di sesso femminile. Awkward .

  • In un'altra società, un ragazzo è stato davvero preso con ASCII art e ha inserito ogni sorta di arte nel suo codice sorgente, non individuato (o forse benedetto) dai revisori del codice. Dopo un po ', si è soffermato sui draghi , per qualche motivo, di solito con una sorta 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 foto, ma poi offeso quando alcuni dei le sciocche tag line potrebbero 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.

41
JBRWilkinson

Se stai vendendo 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.

24
Peter Turner

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 di giurati ostili in qualche momento. Ciò significa che i nomi delle variabili e delle funzioni non devono 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, in che modo una giuria ostile vedrebbe 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 le 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.

17
oosterwal

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

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

9
Sergio

Potrei non essere la persona giusta da chiedere poiché 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 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- lingua /

7
the JinX

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.

6
rjzii

È 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.

5
Stephen C

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 spesso si può ascoltare la stessa lingua scambiata nelle discussioni parlamentari.

La volgarità 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 rivolte 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 chi paga il mio stipendio.

Una rapida soluzione a questo problema consiste nell'installare un filtro volgarità sul sistema di controllo del codice sorgente (come script di presentazione o controllo regolare).

5
Uri

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 # ...

3

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 interessarsi così tanto (o andare all'altro estremo).

Sono sempre dell'idea che qualsiasi commento (in codice o commit) dovrebbe essere tile. 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 ogni tanto 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 al riguardo, vai a chiamare il manager. Se non ricevi supporto dal gestore, dovrai imparare a conviverci o andare altrove.

2
Berin Loritsch

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. Quello che 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.

1
Bill

Se vedi parolacce nel software open source e vuoi sbarazzartene, preparati alla possibilità di Push-back. Non limitarti a scrivere un segnalazione bug su tre righe e aspettarti che venga accettato. Scrivi un mini-saggio che spiega perché parolacce e linguaggio discriminatorio sono cattivi e anticipa le confutazioni.

1
Andrew Grimm

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.)

1
dsimcha

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 danno fastidio t? 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.

0
Marcie