In che modo le persone affrontano volgarità nel codice sorgente e nei commenti VCS. Conserva o cancella?
E riguardo le soft-expletive come WTF o Arrgggh?
È poco professionale, offensivo o qualcosa per cui essere scrollato di dosso?
Dovrebbe essere scoraggiato delicatamente
.. non puoi sapere chi potrà vedere il codice sorgente durante la sua vita.
Mentre è tutto parte del lavoro essere frustrato con un pezzo di codice particolarmente complesso o vecchio e volerne suonare, inserire nel codice sorgente imprecisioni / rant / arte ASCII / battute cattive / commenti offensivi è non professionale e una 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:
Mentre tutti abbiamo bisogno di avere qualche sbocco per frustrazione / divertimento / japing, il codice sorgente non è il posto giusto per farlo, IMO. Non inserirai imprecazioni / battute / commenti offensivi in un contratto, pagine di aiuto, progetti o altri documenti professionali, anche se tali documenti potrebbero essere letti anche meno frequentemente del codice sorgente.
Se i capigruppo se la prendono con tutte le mani in mano, sarà sconvolto, quindi dico "gentilmente scoraggiato" per mezzo di una parola tranquilla con i tecnici dei problemi e fornisco meccanismi di ventilazione adeguati per sfogare, che si tratti di Facebook , instant messaging, air hockey o punch-bag.
Non è difensore affermare che i commenti siano compilati sia - che dire di JavaScript, o di qualsiasi altro codice dinamico lato client?
Ecco alcune delle esperienze del mondo reale che hanno dato forma alla mia opinione:
Mentre lavoravo in Microsoft, ho notato che un ingegnere del software non conosceva l'ortografia corretta di "could not" - ha perso la o, la e la d - e aveva disseminato gran parte del suo codice con lunghe spiegazioni di come non è riuscito a far funzionare X perché la persona Y stava causando il problema Z. Il suo codice era ottimo; la sua ortografia non era così buona. Basti dire che qualsiasi revisore successivo di questo codice (ad esempio me) è stato allarmato dal vedere un gran numero di errori casuali nel codice. Alcuni di questi codici sono stati mostrati ai partner (autori di driver). Immagina il loro orrore nel vedere le imprecazioni. I rilanci avrebbero idealmente dovuto essere al responsabile del progetto in forma verbale (nel qual caso la persona Y potrebbe essere coinvolta nella discussione) o forse impegnare messaggi, ma non nella fonte.
In una compagnia, una persona che parlava una lingua straniera si era unita a una squadra prevalentemente di lingua inglese. Ha scritto commenti nella sua lingua, pensando che nessun altro avrebbe potuto leggerli. Questo andava bene, fino a quando Babelfish / Google Translate ha rilasciato un'opzione "per l'inglese" per la sua lingua, a quel punto il resto del team ha tradotto alcuni commenti ed era inorridito dai commenti sporchi e spesso sprezzanti che il ragazzo aveva fatto riguardo alla compagnia , la sua squadra e una collega di sesso femminile. Awkward .
In un'altra azienda, un ragazzo è stato davvero preso con l'arte ASCII e ha inserito ogni sorta di arte nel suo codice sorgente, non macchiato (o forse benedetto) dai revisori del codice. Dopo un po ', si soffermò sui draghi, per qualche ragione, di solito con qualche tipo di tag line. Più tardi, una persona gallese si è unita al team. L'emblema nazionale del Galles è un drago rosso, quindi il nuovo ragazzo era inizialmente allegro per le immagini, ma poi si offese quando alcune delle sciocche linee di tag potevano essere interpretate come offensive. Sì, è necessaria una mediazione per team leader, ma ciò non avrebbe dovuto accadere.
Nomi / specifiche rimosse per proteggere gli innocenti.
Se stai vendendo il tuo codice sorgente (ad esempio sei uno scrittore di componenti), probabilmente non dovrebbe esserci.
Se è una questione di pudore, allora qualsiasi cosa, dipende da te.
Se vedi qualcuno scrivere molti WTF, forse è un segnale che dovresti parlare loro dei problemi che stanno avendo.
Se qualcuno sta dirigendo la loro aggressione verso un codice di un'altra persona, allora potrebbero tormentare quella persona e hai una situazione completamente diversa da affrontare. Forse hanno una lagnanza legittima e non sanno come doppiarli correttamente. Forse sono solo un coglione.
Non sarebbe saggio avere solo una sorta di filtro dei contenuti, qualunque cosa uno scrittore scrive sia importante e ti dice molto su come stanno andando le cose.
Lavoro per una società Fortune 500 che progetta, produce e vende prodotti di consumo che dispongono di μControllers con codice in esecuzione sviluppato internamente. Il contenzioso è sempre una possibilità, sia da parte dei consumatori che sperano di arricchirsi rapidamente, sia da parte dei concorrenti che chiedono la violazione. Per questo motivo, scriviamo il nostro codice e TUTTI i commenti con la consapevolezza che potrebbe (probabilmente lo farà) venire sotto il controllo di giurati ostili in un dato momento. Ciò significa che i nomi delle variabili e delle funzioni non dovrebbero includere termini di incitamento, come KILL_CHILD(int process_id) . Mentre lo scopo di questa funzione esemplificativa potrebbe benissimo essere quello di terminare i processi figli, in che modo una giuria ostile potrebbe vedere il nome della funzione se il figlio dell'attore è stato ucciso mentre utilizzava il prodotto?
I commenti nel codice possono essere anche peggiori. Mentre un team di difesa decente potrebbe probabilmente gestire spiegando cosa sia un processo figlio (dal precedente esempio) e perché potrebbe dover essere risolto, sarebbe quasi impossibile difendersi da un commento del tipo:
// The following section of code is REALLY BAD!!! I hope
// it doesn't burn anybody's house down.
Commenti non ufficiali come quelli che hanno preso in considerazione fattori in casi reali.
Su un argomento correlato, anche i nomi dei progetti possono essere schiaccianti al microscopio di un contenzioso intenso. Ricordi il clamore dei gruppi conservatori a metà degli anni '90 quando le fonti di notizie tecnologiche riportarono "SATAN Unleashed On The Internet" ?
< rant_mode_off >
Con tutto ciò che è stato detto, per i progetti personali sei libero di fare ciò che ti piace nel tuo codice.
Se ti dà fastidio e tu sei il capo, non vedo perché non potresti applicare una regola al riguardo. sei dopo tutto il leader in questa situazione ipotetica.
Tuttavia, se ti dà fastidio solo a te e a nessun altro sembra dispiacere, forse dovresti solo succhiarlo.
Potrei non essere la persona giusta da chiedere poiché uso spesso un linguaggio volgare.
Penso che dipenda principalmente dal modo in cui PC (politically correct) è il tuo ambiente.
Se codice per una società di giacca e cravatta, proverei a non usare parolacce, ma se è per un progetto di un hobby o qualcosa tendo a dire 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 in cui vivo e lavoro.
Come bonus aggiuntivo, ecco alcune statistiche su volgarità nel codice: link
Sono incline a concordare che può essere piuttosto poco professionale, ma ognuno di voi fa di tanto in tanto, quindi cerco di non tenerlo contro gli altri. Detto questo, il codebase tende a riflettere la professionalità complessiva del gruppo, quindi un codice base esplicativo può riflettere un gruppo non professionale e potrebbe essere necessario un incontro per "applicare un po 'di lucido" al gruppo. Allo stesso modo, se alcune tendenze appaiono nel codice, potrebbe essere un indicatore di problemi generali all'interno del gruppo che devono essere risolti (cioè l'API con cui stai lavorando ha problemi che sono degli sviluppatori frustranti).
In termini di codebase, 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 un cliente.
Uno dei problemi con parolacce è che è diverso da cultura a cultura. Negli Stati Uniti la roba innocente tende ad essere "bipata", mentre in altri paesi spesso si sente 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 mette fuori legge le uova di Pasqua.
Personalmente ritengo che le cose che non riguardano i 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 tutte queste cose, 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 piegarmi ai regolamenti di coloro che pagano il mio stipendio.
Una soluzione rapida a questo problema è l'installazione di un filtro osceno sul sistema di controllo del codice sorgente (come script di presubmit o controllo regolare).
Is this unprofessional, offensive or something to be shrugged off?
Forse tutti e tre ... a seconda del tuo punto di vista.
E 'nella natura umana che le persone si esprimano usando "linguaggio colorato" in determinate situazioni. Più così 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 voglia renderti impopolare con i tuoi compagni di lavoro.
Tuttavia, se il codice sorgente / i commenti VCS vengono pubblicati all'esterno dell'organizzazione, la tua gestione potrebbe voler prendere una linea più strong, sulla base del fatto che è un male per le aziende offendere i tuoi clienti.
Penso che sia ok finchè non è fuori controllo come far cadere le bombe di f lì. Ho visto un ragazzo con cui lavoro scrivere una sceneggiatura tra due personaggi che discutono dei vari oggetti che rappresentano ciascuno. C'era un commento multilinea che correva come 30 righe di questi due personaggi che si scambiavano l'un l'altro.
/ * * igor: devo diventare un massaggiatore pubblico? * Frankenstein: ah igor, erediterò dai tuoi tratti migliori ... * /
È andato avanti così per molto tempo. Ha creato due oggetti chiamati, hai 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 di 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 decisamente sgradite. D'altra parte, uno sviluppatore di giochi potrebbe non preoccuparsi così tanto (o andare all'estremo opposto).
Sono sempre convinto che qualsiasi commento (in codice o in 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 aggirarlo.
Detto questo, non uso imprecazioni ma occasionalmente uso cose come "Doh!" o "Huh?" che non è molto diverso nello spirito. Se ti infastidisce, ne parli con il colpevole - potrebbe non pensarci. Se ti dicono di fare un'escursione e ne senti strongmente, vai su al direttore. Se non ricevi supporto dal manager, dovrai imparare a conviverci o ad andare altrove.
Beh, non sono esattamente sicuro di cos'altro dovresti dire su codice come questo:
tocommit = (n + (COMMITSIZE/PAGESIZE) - 1) & ~(COMMITSIZE/PAGESIZE - 1);
Questo codice è stato estratto da una base di codice reale, estremamente cruenta, che ho cercato di ottimizzare ultimamente. (Il codice è open source, quindi non sto rivelando i segreti di qualsiasi datore di lavoro qui o altro.)
Come altri hanno già detto, dipende dal posto di lavoro e chi vedrà il codice sorgente.
Se vendessi il codice sorgente avrei un secondo repository di sole versioni rilasciate e non permetterò nessun commento di controllo in là al di fuori di una descrizione di ciò che ogni nuova versione fornisce. Quello che faccio di giorno in giorno e tutti i miei passi falsi sono tra me e la mia squadra, non i miei clienti.
Attualmente il mio server di build riporta i commenti OMG, WTF, kludge, mess e TODO come una metrica di pulizia rimanente per farlo adesso sono parte del processo.
Se vedi parolacce nel software open source e vuoi liberartene, prepara la possibilità di un push-back. Non limitarti a scrivere un rapporto bug di tre righe e aspettarti che venga accettato. Scrivi un mini-saggio che spiega perché il linguaggio volgare e discriminatorio è cattivo e previeni le confutazioni.
Penso che sia una questione di preferenze personali. Quella roba non mi infastidisce, quindi probabilmente lo lascerei. Potrebbe persino darmi un suggerimento su dove si trovano le aree problematiche nel codice.
Ti danno fastidio tu ? Dal fatto che tu stia facendo questa domanda, suppongo che lo facciano. In tal caso, rimuovili o puliscili in commenti più appropriati su ciò che è sbagliato.
Leggi altre domande sui tag source-code