Traiter les blasphèmes dans le code source [fermé]


34

Comment les gens gèrent-ils les blasphèmes dans le code source et les commentaires VCS? Conserver ou supprimer?

Qu'en est-il des soft-expletives comme WTF ou Arrgggh?

Est-ce un manque de professionnalisme, une offense ou quelque chose qui doit être ignoré?


15
Au cas par cas ... les commentaires sont une avenue pour la personnalité des développeurs. Tout comme vous devez gérer N types de personnalités, vous devez également traiter N types de commentaires qui saignent la personnalité des développeurs. Comment traitez-vous avec un développeur donné en utilisant le blasphème lorsque vous interagissez avec eux par messagerie instantanée, courrier électronique, verbalement?
Aaron McIver

10
Avant de ne pas mettre de blasphème dans les commentaires, j’ai dû dire à certains développeurs Jr. IMHO c'est très peu professionnel. Si vous ne jurez pas devant vos collègues ou vos clients, pourquoi ajoutez-vous des commentaires / codes? Et si vous juriez devant vos collègues et vos clients ... votre environnement de travail serait beaucoup plus décontracté que moi. :)
Tyanna

4
@Tyanna: Dans mon dernier lieu de travail, nous étions même un peu racistes! Si vous pouvez appeler ça comme ça. Je pense que le politiquement correct est affreux parmi les collègues qui se voient jour après jour. Auriez-vous peur de raconter une blague raciste à quelqu'un que vous voyez 10 heures par jour? Encore une fois, je vis en Bolivie - je pense que les États-Unis ont une mentalité beaucoup plus suicidaire, suicidaire, et c'est pourquoi personne ne veut faire un pas sur les pieds.

4
@Anna Lear: Jamais de quelqu'un ayant été poursuivi en justice au Danemark pour avoir raconté une blague épicée. Les États-Unis cependant ... Tout dépend de l'ambiance dans laquelle vous travaillez. Les États-Unis ont plus de poids sur les drones HR qui surveillent chaque chose.

10
Faites juste un grep f.cksur le code source d’un noyau Linux. Si c'est assez bon pour eux, c'est assez bien pour moi. Mais n'offrez jamais rien d'offensif dans des endroits où il y a la moindre chance que les clients le remarquent. Je l'ai fait une fois et heureusement, nous avons réussi à extraire la mise à jour à la dernière minute, mais ce n'était pas amusant. (En fait, c'était après.)
biziclop

Réponses:


41

Il faut se décourager doucement

..vous ne pouvez pas savoir qui peut voir le code source tout au long de sa vie.

Bien que le fait de frustrer un morceau de code particulièrement complexe ou ancien et de vouloir en parler soit une partie du travail, il est à la fois peu professionnel et insignifiant de mettre en scène des blagues / remarques offensantes / de l'art ASCII / dans le code source. mauvaise idée dans mon expérience. Parfois, l'ingénieur qui rédige les commentaires ignore les éventuels effets que pourraient avoir ses commentaires - voici quelques-uns des problèmes que j'ai vus:

  • Un grand nombre d'explosifs dans le code publiés au public sous forme de code open source / exemple.
  • Blagues de mauvais goût causant une offense profonde à certains membres de l'équipe aboutissant à un tribunal du travail.
  • Jeter des propos qui étaient en réalité racistes / sexistes / sexistes et qui ont provoqué le licenciement de personnes.

Bien que nous ayons tous besoin de points de vente pour la frustration / le plaisir / la détente, le code source n’est pas l’endroit idéal pour le faire, IMO. Vous ne mettriez pas d'explosifs / blagues / commentaires offensants dans un contrat, des pages d'aide, des plans, ou tout autre document professionnel, même si ces documents peuvent être lus encore moins souvent que le code source.

Si les chefs d’équipe s’imprègnent de tout leur courage, ils seront bouleversés, alors je dis «doucement découragé» par un mot discret avec les ingénieurs qui ont des problèmes et en leur fournissant des mécanismes de ventilation appropriés, que ce soit Facebook ou la messagerie instantanée. , air hockey ou un punch-bag.

Ce n'est pas une défense de dire que les commentaires sont non plus compilés - qu'en est-il de JavaScript ou de tout autre code dynamique côté client?

Voici quelques-unes des expériences réelles que j'ai vécues qui ont façonné mon opinion:

  • Tout en travaillant chez Microsoft, je remarquai qu'un ingénieur logiciel ne savait pas l'orthographe correcte de « ne pouvait pas » - il a raté le o, l et d - et avait truffé une grande partie de son code avec des explications longues de la façon dont il ne pouvait pas faire travailler X parce que la personne Y posait le problème Z. Son code était génial; son orthographe n'était pas si bonne. Autant dire que tout relecteur ultérieur de ce code (par exemple moi) était alarmé de voir un grand nombre de jurons aléatoires dans le code. Une partie de ce code a ensuite été montrée aux partenaires (rédacteurs de pilotes). Imaginez leur horreur de voir les jurons. Les coups de gueule auraient dû idéalement être adressés verbalement au chef de projet (dans ce cas, la personne Y pourrait participer à la discussion) ou éventuellement transmettre des messages, mais pas à la source.

  • Dans une entreprise, une personne parlant une langue étrangère a rejoint une équipe essentiellement anglophone. Il a écrit des commentaires dans sa langue, pensant que personne d'autre ne pouvait les lire. C'était parfait, jusqu'à ce que Babelfish / Google Translate publie une option "vers l'anglais" pour sa langue. Le reste de l'équipe traduit alors quelques commentaires et est choqué par les commentaires sales et souvent désobligeants qu'il a tenus à propos de la société. , son équipe et une collègue de travail. Maladroit .

  • Dans une autre société, un type était vraiment pris par l'art ASCII et a mis toutes sortes d'art dans son code source, non noté (ou peut-être béni) par les réviseurs de code. Après un certain temps, il a insisté sur les dragons, pour une raison quelconque, généralement avec une sorte de slogan. Plus tard, un Gallois a rejoint l’équipe. L'emblème national du pays de Galles est un dragon rouge. Le nouveau type était donc enthousiasmé par les images, puis offensé lorsque certaines des idioties ridicules pouvaient être considérées comme offensantes. Oui, une médiation de chef d'équipe est nécessaire, mais cela n'aurait pas dû arriver.


Noms / détails supprimés pour protéger l'innocent.


1
J'ajouterais que les profanations dans votre système de suivi des défauts ne devraient pas non plus être encouragées. Ayant été dans la position de demander à un auteur de modifier son commentaire pour supprimer le blasphème, je peux vous dire que ce n'est pas une position agréable pour un superviseur / chef d'équipe / responsable. Spécialement quand ils refusent.
Rapidement maintenant

@quickly_now, comment avez-vous géré cette situation alors?

J'ai encore demandé. Lorsque la personne a de nouveau refusé, j'ai modifié moi-même les commentaires pour les assainir. Je ne pensais pas que cela valait la peine de passer par le processus de conseil / discipline (étape n ° 1 menant au licenciement), mais j'ai aussi signalé à mon patron ce que j'avais trouvé et fait. Nous avons tous convenu que cela n'irait pas plus loin à moins d'être répété (et cela n'a pas été répété). Pas drôle. [J'ajouterais que les commentaires profanes m'ont été rapportés par un autre membre du personnel concerné. Cela a fait mon problème à résoudre. Parfois, les postes de direction ne valent pas le supplément de dollars !!!]
quick_now

"Mais ensuite offensé quand certaines des slogans idiots pourraient être considérés comme offensants." Vous devriez être une personne TRÈS profondément perturbée pour être offensée par une image d'un dragon parce que vous êtes gallois.
Miles Rout

24

Si vous vendez votre code source (c'est-à-dire que vous êtes un auteur de composant), il ne devrait probablement pas y figurer.

Si c'est une question de prudence, alors peu importe, c'est à vous de décider.

Si vous voyez quelqu'un écrire beaucoup de WTF, c'est peut-être un signe que vous devriez leur parler des problèmes qu'ils rencontrent.

Si une personne dirige son agression vers le code d'une autre personne, elle peut alors la harceler et vous devez faire face à une situation complètement différente. Peut-être qu'ils ont une plainte légitime et ne savent pas comment l'exprimer correctement. Peut-être qu'ils ne sont qu'un imbécile

Il ne serait pas sage d’avoir un filtre de contenu, peu importe ce que le développeur écrit est important et cela en dit long sur l’évolution de la situation.


1
+1 pour le point de ne pas vendre de code source à charge explitive. Le code doit être minutieusement inspecté avant d’être livré.
FrustratedWithFormsDesigner

2
Les commentaires désagréables ne sont certainement pas une bonne idée si vous êtes un développeur HTML. :)
biziclop

@biziclop, ce qui est regrettable car le langage HTML est aussi frustrant qu’un langage possible. Consultez le lien de @ the jinx sur les taux de blasphème dans la source. ressemble à javascript est lié pour la première (je ne sais pas si cela inclut javascript javascript minified accidentel)
Peter Turner

Notre filtre de contenu simple fonctionnant sur jenkins avait un problème avec ceci: void pushItem (...
sal

17

Je travaille pour une entreprise du classement Fortune 500 qui conçoit, fabrique et vend des produits de consommation pour lesquels µControllers exécute du code développé en interne. Les litiges sont toujours une possibilité, que ce soit des consommateurs qui souhaitent s'enrichir rapidement ou des concurrents qui prétendent être en infraction. Pour cette raison, nous écrivons notre code et TOUS les commentaires en sachant qu'il pourrait (probablement) être soumis à l'examen minutieux de jurés hostiles à un moment donné. Cela signifie que les noms de variable et de fonction ne doivent pas inclure de termes incitants, comme KILL_CHILD(int process_id). Bien que l'objectif de cet exemple de fonction puisse très bien être de mettre fin aux processus enfants, comment un jury hostile verrait-il ce nom de fonction si l'enfant du demandeur était tué en utilisant le produit?

Les commentaires dans le code peuvent être encore pires. Même si une équipe de défense décente pourrait probablement expliquer en quoi consiste un processus enfant (à partir d’exemple précédent) et pourquoi il pourrait être nécessaire de l’interrompre, il serait presque impossible de se défendre contre un commentaire tel que:

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

De tels commentaires spontanés ont été déterminants dans de véritables affaires judiciaires.

Sur un sujet connexe, les noms de projets peuvent également être accablants lorsque vous êtes sous le microscope d’un contentieux intense. Vous souvenez-vous du tumulte des groupes conservateurs au milieu des années 90, lorsque des sources d'informations technologiques ont rapporté "SATAN Unleashed On The Internet" ?

<rant_mode_off>

Cela dit, pour vos projets personnels, vous êtes libre de faire ce que vous aimez dans votre code.


1
+1 pour signaler l’aspect le plus dangereux de ce comportement IMPROFESSIONNEL. J'ai travaillé sur des équipes de "due diligence" qui ont examiné le code source des entreprises pour lesquelles le F500 pour lequel je travaillais était sur le point d'acheter. Nous avons cherché ce genre de choses pour les raisons que vous avez mentionnées et cela a fait une différence de savoir qui a obtenu un emploi permanent et qui ne l'a pas été lorsque la fusion a été réalisée. En particulier, une grande entreprise (coffres profonds) n'achète pas une petite entreprise pour hériter de poursuites pour harcèlement / environnement de travail hostile, de sorte que les contrevenants soient licenciés / licenciés une fois l'achat terminé.
Kloucks

5
KILL_CHILD n'est qu'un exemple absurde. Et j'aimerais voir la citation sur "Les commentaires comme ceux-là ont été déterminants dans les affaires judiciaires réelles". (Je ne dis pas seulement cela en tant que STFU ... J'aimerais vraiment lire la citation.)
Wolfger


1
"Cela signifie que les noms de variable et de fonction ne doivent pas inclure de termes incitants, tels que KILL_CHILD". C’est la chose la plus stupide que j’ai jamais lue et vous devriez avoir honte d’impliquer même que KILL_CHILD est un mauvais nom pour une fonction.
Miles Rout

9

Si cela vous dérange et que vous êtes le chef honoraire, je ne vois pas pourquoi vous ne pourriez pas appliquer de règle à ce sujet. Vous êtes après tout le leader dans cette situation hypothétique.

Cependant, si cela ne vous dérange pas et que personne d'autre ne semble s'en soucier, vous devriez peut-être vous contenter de la perdre.


Voici la chose: je ne "aspire" pas les choses.
gnasher729

7

Je ne suis peut-être pas la bonne personne à qui demander, car j'utilise souvent des blasphèmes légers.

Je pense que cela dépend surtout de votre environnement (politiquement correct).

Si je codais pour une entreprise de costumes et de cravates, j'essaierais de ne pas utiliser de blasphème du tout, mais s'il s'agit d'un projet de loisir ou de quelque chose, j'ai tendance à parler plus librement.

Il me semble qu'aux États-Unis et dans certains autres pays, les gens sont beaucoup plus exposés aux ordinateurs qu'aux Pays-Bas où je vis et travaille.

En prime, voici quelques statistiques sur le blasphème dans le code: http://andrewvos.com/2011/02/21/amount-of-profanity-in-git-commit-messages-per-programming-language/


1
Je pense que c'est plus dépendant du secteur - dans un environnement à haute pression comme celui de la finance, les explétives sont courantes.
JBRWilkinson

cela dépend aussi beaucoup de ce que vous considérez comme une "profanation". Comme dans l'article lié, "lol" et "rofl" ont été choisis comme des blasphèmes, alors que la plupart d'entre nous, je pense, ne les classeront pas comme tels.
Jwenting

Ce n’est pas à propos de PC, mais à propos de l’utilisation appropriée de la langue (vous pouvez être tout à fait pas PC et choisir de ne pas utiliser de blasphème - vous pouvez être profondément offensant et grossier et ne pas utiliser de blasphème). Il faut penser à ne pas offenser indûment - parce que presque tout est offensant pour quelqu'un - mais la plupart d'entre nous savons où en est la ligne et jure généralement que les paroles sont du mauvais côté. La retenue dans cette zone est utile - si vous ne jurez pas beaucoup ou souvent alors vous prenez note ...
Murph

6

Je suis enclin à convenir que cela peut être assez peu professionnel, mais tout le monde s'exprime de temps en temps, alors j'essaie de ne pas le reprocher. Cela dit, la base de code a tendance à refléter le professionnalisme général du groupe. Ainsi, une base de code chargée de manière explicative pourrait refléter un groupe non professionnel et une réunion pourrait être nécessaire afin d '"appliquer un peu de polissage" au groupe. De même, si certaines tendances apparaissent dans le code, cela pourrait indiquer les problèmes généraux à résoudre au sein du groupe (par exemple, l'API avec laquelle vous travaillez a des problèmes frustrants pour les développeurs).

Pour ce qui est de la base de code, je modifie généralement le commentaire pertinent pour que le travail soit sans danger et le reste. En fonction de la langue dans laquelle vous travaillez, c'est toujours une bonne idée, car vous ne savez jamais ce qui peut apparaître devant un client ou un client.


3
+1, Intéressant, je n'avais pas pensé à utiliser des schémas d'apparences explétives pour suivre la frustration liée à des fonctions / bibliothèques particulières.
FrustratedWithFormsDesigner


5

Est-ce que c'est non professionnel, offensant ou quelque chose qui doit être ignoré?

Peut-être tous les trois ... selon votre point de vue.

C'est la nature humaine pour les personnes de s'exprimer en utilisant "un langage coloré" dans certaines situations. Plus dans certaines cultures que dans d'autres, et certaines personnes plus que d'autres. Mais la tendance est universelle.

Si j'étais à votre place, je m'en débarrasserai à moins que vous ne vouliez vous rendre impopulaire auprès de vos collègues de travail.

Toutefois, si les commentaires de code source / VCS sont publiés en dehors de votre organisation, votre direction voudra peut-être adopter une position plus ferme, estimant qu'il est mauvais pour les entreprises d'offenser vos clients.


La clé ici est "dans certaines situations" - c'est-à-dire lorsque cela est approprié et acceptable. Je pense qu'il est raisonnable de suggérer que les commentaires (code ou commit) ne sont pas des endroits vraiment acceptables et donc inappropriés.
Murph

5

L’un des problèmes que pose le blasphème, c’est que cela diffère d’une culture à l’autre. Aux États-Unis, les actes d'innocence ont tendance à "disparaître", alors que dans d'autres pays, on entend souvent la même langue échangée lors des débats parlementaires.

La profanation dans le code et les commentaires de validation est assez courante, probablement à cause de la vue "personne ne la verra". Je pense qu'il est plus courant maintenant que la plupart des organisations interdisent les œufs de Pâques.

Personnellement, je pense que les problèmes rencontrés par les non-clients (tels que les matériaux de validation internes) ne sont pas un si gros problème.

Cependant, la plupart des grandes multinationales sont dirigées par des services juridiques et par un "lieu de travail sûr" et ainsi de suite, ce qui signifie que tout ce qui pourrait blesser au moins une personne est un problème et un motif potentiel de licenciement. Je déteste l'admettre, mais j'ai tendance à me plier aux règlements de ceux qui paient mon salaire.

Une solution rapide à ce problème consiste à installer un filtre grossier sur votre système de contrôle de code source (en tant que script de soumission préalable ou vérification régulière).


2
Je suis en désaccord avec votre suggestion d'un filtre automatique de blasphème. Premièrement, vous risquez de vous heurter au problème Scunthorpe et, deuxièmement, comme le dit Stephen C, les blasphèmes sont probablement le symptôme d'un autre problème et l'interdire ne résoudra pas le problème par magie.
Scott

2
+1 Pour le filtre de blasphème, mais il est important d'éviter l'erreur " classique " ( thedailywtf.com/Articles/The-Clbuttic-Mistake-.aspx )
rjzii 23/02/2011

les filtres à grossièretés ne fonctionnent pas. Ils ont tendance à bloquer les choses innoces et à laisser passer les mauvaises choses. Ils ont également tendance à être facile à contourner.
Jwenting

cntd. Je fais de la modération pour un forum de photographie de nature. Lorsque les administrateurs ont décidé d'installer un filtre grossier, toutes les discussions sur les castors, les chats d'animaux de compagnie, les oiseaux, etc., étaient censurées. Avant qu'il ne soit à nouveau supprimé, les utilisateurs ont commencé à développer des méthodes autour du filtre. Si vous ne pouvez pas parler de votre voyage pour tirer sur les castors (oups, 3 gros mots dans une phrase courte), vous parlez de votre tr.ip à sh.oo.t be.ave.rs à la place par exemple et le filtre va être trop stu.pi.d (un autre mot qui a été interdit) pour l'attraper.
Jwenting

Pour moi, l'argument selon lequel il faut éviter les filtres de blasphème "parce que beaucoup d'entre eux sont de la merde" est tout aussi logique que d'éviter les filtres anti-spam, les désinfectants SQL, etc. Il existe de bonnes options pour les tiers. Si vous utilisez uniquement les expressions rationnelles, vous êtes SOL.
Uri

3

Je pense que ça va tant que ce n'est pas incontrôlable, comme lancer des bombes là-bas. J'ai vu un gars avec qui je travaille écrire un script entre deux personnages pour discuter des différents objets qu'ils représentent. Il y avait un commentaire multiligne qui durait comme une trentaine de lignes de ces deux personnages qui se parlaient.

/ * * igor: dois-je me rendre masster public? * Frankenstein: ah igor, je vais hériter de tes meilleurs traits ... * /

Cela a duré comme ça pendant longtemps. Il a créé deux objets appelés, vous l'avez deviné: Frankenstein et Igor dans le cadre d'une vérification de cohérence. C'était en fait très créatif mais une perte de temps totale. J'aurais préféré voir quelques WTF ou expletives plutôt qu'un scénario entre deux objets C # ...


Ca c'est drôle. Non productif, mais drôle.
Paul Nathan

@Paul: Ha! Désolé, oui - pas très productif, mais c'était ridicule de voir ce jour-là en regardant à travers un code.
Nodey The Node Guy

2

Dépend de la culture de l'entreprise / du client. Par exemple, si vous développez un logiciel biblique, les textes explicites, quelle que soit leur forme, sont définitivement malvenus. D'un autre côté, un développeur de jeux peut ne pas s'en soucier autant (ou aller à l'extrême extrême).

Je suis toujours convaincu que tout commentaire (en code ou en commet) devrait être utile . Certains mots attirent plus notre attention que d’autres - les explétives, même les variétés douces, sont clairement remarquées. Il peut être utile d’attirer l’attention sur quelque chose qui ne va tout simplement pas, mais vous n’avez pas le moyen de le contourner pour le moment.

Cela dit, je n’utilise pas d’explosifs, mais j’utilise parfois des choses comme «Doh! ou "Hein?" qui n'est pas trop différent d'esprit. Si cela vous dérange, parlez-en avec le délinquant - il / elle ne pense peut-être pas à cela. S'ils vous disent de faire une randonnée et que vous y tenez vraiment, allez au directeur. Si le responsable ne vous soutient pas, vous devrez apprendre à vivre avec ou à aller ailleurs.


Désolé, quel est le "logiciel de la Bible"? (pas un anglais d'origine ici).
Rook

2
La Bible est l'endroit où la doctrine chrétienne est écrite. Un logiciel biblique est un logiciel que les chrétiens peuvent utiliser pour examiner le texte dans différentes traductions, rechercher ce que les érudits ont dit à propos d'un certain passage et, en général, étudier le texte. Une Écriture parle de «Ne laissez aucune communication corrompue sortir de votre bouche», ce qui est du vieil anglais car il ne faut pas bavarder, ou parler de choses qui déchirent les gens. Je suis sûr qu'il existe d'autres applications religieuses pour lesquelles les malédictions seraient tout aussi indésirables.
Berin Loritsch

3
Les chrétiens désassemblent les exécutables pour rechercher des mots maudits dans la source?

Euh, les commentaires ne sont pas compilés, donc ça ne marcherait même pas;)
le JinX

5
Donc si j'écris un logiciel biblique, je devrais censurer tout ce qui est obscène dans la Bible?
Wooble

1

Eh bien, je ne sais pas exactement quoi d'autre vous êtes censé dire à propos d'un code comme celui-ci:

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

Ce code a été extrait d'une base de code réelle et extrêmement cruelle que j'ai essayé d'optimiser récemment. (Le code est open source, donc je ne révèle aucun secret d'employeur ici ou quoi que ce soit.)


3
Tuez ce sumbitch avec du feu et un aimant!

1

Comme d’autres l’ont dit, cela dépend du lieu de travail et du nom du code source.

Si je vendais le code source, j'aurais un deuxième dépôt contenant uniquement les versions publiées et ne permettrais à aucun commentaire d'archivage de figurer à l'extérieur de la description fournie par chaque nouvelle version. Ce que je fais au jour le jour et tous mes faux pas sont entre moi et mon équipe, pas avec mes clients.

Actuellement, mon serveur de compilation présente des commentaires sur les commentaires OMG, WTF, kludge, mess et TODO en tant que mesure du nettoyage restant à effectuer. Ils font donc partie du processus.


1

Si vous voyez des blasphèmes dans les logiciels open source et que vous souhaitez vous en débarrasser, préparez-vous à la possibilité d'un refoulement. Ne vous contentez pas d’écrire un rapport de bogue sur trois lignes et attendez-vous à ce qu’il soit accepté. Rédigez un mini-essai expliquant pourquoi le langage vulgaire et discriminatoire est mauvais et prévenez les réfutations.


0

Je pense que c'est une question de préférence personnelle. Ce genre de choses ne me dérange pas vraiment, alors je le laisserais probablement. Cela pourrait même me donner un indice sur les zones à problèmes dans le code.

Est-ce qu'ils vous dérangent ? Du fait que vous posez cette question, je suppose qu'ils le font. Dans ce cas, supprimez-les ou supprimez-les en commentaires plus appropriés sur ce qui ne va pas.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.