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

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é?

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.

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.

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.

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.

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/

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.

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.

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

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

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.

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

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.

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.

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.