it-swarm-eu.dev

Umgang mit Obszönitäten im Quellcode

Wie gehen Menschen mit Obszönitäten im Quellcode und in VCS-Kommentaren um? Behalten oder löschen?

Was ist mit Soft-Expletiven wie WTF oder Arrgggh?

Ist unprofessionell, beleidigend oder etwas, das man abschütteln sollte?

34
sal

Es sollte sanft entmutigt werden

..sie können unmöglich wissen, wer den Quellcode während seiner Lebensdauer sehen wird.

Während es Teil der Arbeit ist, mit einem besonders komplexen oder alten Code frustriert zu sein und darüber zu sprechen, ist es sowohl unprofessionell als auch a, Expletives/Rants/ASCII-Kunst/schlechte Witze/beleidigende Bemerkungen in den Quellcode einzufügen schlechte Idee nach meiner Erfahrung. Manchmal ist sich der Ingenieur, der die Kommentare schreibt, der möglichen Auswirkungen seiner Kommentare nicht bewusst - hier sind nur einige der Probleme, die ich sehe:

  • Eine hohe Anzahl von Expletiven in Code, die als Open-Source-/Beispielcode für die Öffentlichkeit freigegeben wurden.
  • Witze mit schlechtem Geschmack, die einige Teammitglieder zutiefst beleidigen und zu einem Arbeitsgericht führen.
  • Wegwerfbemerkungen, die tatsächlich rassistisch/sexistisch/geschlechtsspezifisch waren und dazu führten, dass Menschen entlassen wurden.

Während wir alle ein paar Outlets für Frustration/Spaß/Japing brauchen, ist der Quellcode nicht der richtige Ort dafür, IMO. Sie würden keine expliziten/Witze/beleidigenden Kommentare in einen Vertrag, Hilfeseiten, Blaupausen oder ein anderes professionelles Dokument einfügen, obwohl diese Dokumente möglicherweise noch seltener als der Quellcode gelesen werden.

Wenn die Teamleiter alles hartnäckig machen, wird es Ärger geben, also sage ich "sanft entmutigt" durch ein leises Wort mit Problemingenieuren und stelle geeignete Entlüftungsmechanismen bereit, um Steam, sei es Facebook, Instant Messaging, abzulassen , Airhockey oder ein Boxsack.

Es ist keine Verteidigung zu sagen, dass Kommentare entweder kompiliert werden - was ist mit JavaScript oder einem anderen dynamischen clientseitigen Code?

Hier sind einige der realen Erfahrungen, die ich gemacht habe und die meine Meinung geprägt haben:

  • Während meiner Arbeit bei Microsoft stellte ich fest, dass ein Softwareentwickler die korrekte Schreibweise von "konnte nicht" nicht kannte - er vermisste das o, l und d - und einen Großteil seines Codes mit langen Erklärungen überhäuft hatte, wie er konnte X nicht zum Arbeiten bringen, weil Y Person Problem Z verursachte. Sein Code war großartig; seine Rechtschreibung war nicht so gut. Es genügt zu sagen, dass jeder nachfolgende Prüfer dieses Codes (z. B. ich) alarmiert war, eine große Anzahl zufälliger Schwüre im Code zu sehen. Ein Teil dieses Codes wurde Partnern (Treiberautoren) gezeigt. Stellen Sie sich ihr Entsetzen vor, die Flüche zu sehen. Die Beschimpfungen sollten idealerweise in mündlicher Form an den Projektmanager gerichtet sein (in diesem Fall kann Person Y in die Diskussion einbezogen werden) oder möglicherweise Nachrichten festschreiben, jedoch nicht in der Quelle.

  • In einem Unternehmen trat eine fremdsprachige Person einem überwiegend englischsprachigen Team bei. Er schrieb Kommentare in seiner Sprache und dachte, dass niemand sonst sie lesen könnte. Dies war in Ordnung, bis Babelfish/Google Translate eine Option "auf Englisch" für seine Sprache veröffentlichte. Zu diesem Zeitpunkt übersetzte der Rest des Teams einige Kommentare und war entsetzt über die schmutzigen und oft abfälligen Kommentare, die der Typ über das Unternehmen abgegeben hatte , sein Team und eine Mitarbeiterin. Umständlich .

  • In einer anderen Firma war ein Mann wirklich begeistert von ASCII Kunst) und fügte alle Arten von Kunst in seinen Quellcode ein, die von Code-Rezensenten nicht entdeckt (oder vielleicht gesegnet) wurde. Nach einer Weile beschäftigte er sich mit Drachen Aus irgendeinem Grund, normalerweise mit einer Art Slogan. Später trat eine walisische Person dem Team bei. Das nationale Emblem von Wales ist ein roter Drache, daher war der neue Typ anfangs fröhlich über die Bilder, aber dann beleidigt, wenn einige von ihnen Die albernen Markierungen könnten als anstößig ausgelegt werden. Ja, eine Vermittlung durch einen Teamleiter ist erforderlich, aber dies hätte nicht passieren dürfen.


Namen/Angaben wurden entfernt, um die Unschuldigen zu schützen.

41
JBRWilkinson

Wenn Sie Ihren Quellcode verkaufen (d. H. Sie sind ein Komponentenschreiber), sollte er wahrscheinlich nicht vorhanden sein.

Wenn es um Prüde geht, dann liegt es an Ihnen.

Wenn Sie jemanden sehen, der viele WTFs schreibt, ist dies vielleicht ein Zeichen dafür, dass Sie mit ihm über die Probleme sprechen sollten, die er hat.

Wenn jemand seine Aggression auf den Code einer anderen Person richtet, belästigt er diese Person möglicherweise und Sie haben eine völlig andere Situation zu bewältigen. Vielleicht haben sie eine berechtigte Beschwerde und wissen nicht, wie sie sie richtig aussprechen sollen. Vielleicht sind sie nur ein Idiot.

Es wäre nicht ratsam, nur eine Art Inhaltsfilter zu haben. Was auch immer ein Entwickler schreibt, ist wichtig und es sagt Ihnen viel darüber aus, wie die Dinge laufen.

24
Peter Turner

Ich arbeite für ein Fortune 500-Unternehmen, das Konsumgüter entwirft, herstellt und verkauft, bei denen µController selbst entwickelten Code ausführen. Rechtsstreitigkeiten sind immer möglich, entweder von Verbrauchern, die darauf hoffen, schnell reich zu werden, oder von Wettbewerbern, die Verstöße geltend machen. Aus diesem Grund schreiben wir unseren Code und ALLE Kommentare mit dem Wissen, dass er möglicherweise (wahrscheinlich) irgendwann von feindlichen Juroren geprüft wird. Das bedeutet, dass Variablen- und Funktionsnamen keine anstößigen Begriffe wie KILL_CHILD(int process_id) enthalten sollten. Während der Zweck dieser Beispielfunktion sehr wohl darin bestehen könnte, untergeordnete Prozesse zu beenden, wie würde eine feindliche Jury diesen Funktionsnamen sehen, wenn das Kind des Klägers während der Verwendung des Produkts getötet würde?

In-Code-Kommentare können noch schlimmer sein. Während ein anständiges Verteidigungsteam wahrscheinlich damit umgehen könnte, zu erklären, was ein untergeordneter Prozess ist (aus dem vorherigen Beispiel) und warum er möglicherweise beendet werden muss, wäre es fast unmöglich, sich gegen einen Kommentar wie den folgenden zu verteidigen:

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

Solche spontanen Kommentare waren entscheidende Faktoren in echten Gerichtsverfahren.

Zu einem verwandten Thema können Namen für Projekte auch unter dem Mikroskop intensiver Rechtsstreitigkeiten schädlich sein. Erinnern Sie sich an den Aufruhr der konservativen Gruppen Mitte der 90er Jahre, als Technologie-Nachrichtenquellen berichteten "SATAN Unleashed On The Internet"?

<rant_mode_off>

Nach alledem können Sie für persönliche Projekte tun, was Sie in Ihrem Code möchten.

17
oosterwal

Wenn es Sie stört und Sie der Haupthoncho sind, verstehe ich nicht, warum Sie eine Regel dazu nicht implementieren konnten. Sie sind immerhin der Anführer in dieser hypothetischen Situation.

Wenn es Sie jedoch nur stört und es niemanden zu stören scheint, sollten Sie es einfach aufsaugen.

9
Sergio

Ich bin möglicherweise nicht die richtige Person, um zu fragen, da ich oft leichte Obszönitäten benutze.

Ich denke, es hängt hauptsächlich davon ab, wie PC (politisch korrekt) Ihre Umgebung ist.

Wenn ich für eine Anzug- und Krawattenfirma codiere, würde ich versuchen, überhaupt keine Obszönitäten zu verwenden, aber wenn es sich um ein Hobbyprojekt oder etwas handelt, neige ich dazu, meine Meinung freier zu äußern.

Es scheint mir, dass in den USA und einigen anderen Ländern die Menschen viel mehr PC (oder Stuck-up) sind als in den Niederlanden, wo ich lebe und arbeite.

Als zusätzlichen Bonus finden Sie hier einige Statistiken zur Obszönität im Code: http://andrewvos.com/2011/02/21/amount-of-profanity-in-git-commit-messages-per-programming- Sprache /

7
the JinX

Ich bin geneigt zuzustimmen, dass es ziemlich unprofessionell sein kann, aber jeder flucht von Zeit zu Zeit, also versuche ich, es nicht gegen andere zu halten. Die Codebasis spiegelt jedoch tendenziell die allgemeine Professionalität der Gruppe wider, sodass eine mit Explosionen beladene Codebasis eine unprofessionelle Gruppe widerspiegeln kann und möglicherweise ein Meeting stattfinden muss, um der Gruppe etwas Glanz zu verleihen. Wenn bestimmte Trends im Code erscheinen, kann dies ebenfalls ein Indikator für allgemeine Probleme innerhalb der Gruppe sein, die gelöst werden müssen (d. H. Die API, mit der Sie arbeiten, weist Probleme auf, die Entwickler frustrieren).

In Bezug auf die Codebasis bearbeite ich normalerweise nur den relevanten Kommentar, um die Arbeit zu gewährleisten, und lasse ihn dabei. Abhängig von der Sprache, mit der Sie arbeiten, ist dies immer eine gute Idee, da Sie nie wissen, was vor einem Kunden oder Kunden erscheinen könnte.

6
rjzii

Ist das unprofessionell, beleidigend oder etwas, das man abschütteln sollte?

Möglicherweise alle drei ... abhängig von Ihrer Sichtweise.

Es liegt in der Natur des Menschen, sich in bestimmten Situationen mit "bunter Sprache" auszudrücken. Mehr in einigen Kulturen als in anderen, und einige Menschen mehr als andere. Aber die Tendenz ist universell.

Wenn ich du wäre, würde ich es abschütteln, wenn du nicht bereit bist, dich bei deinen Arbeitskollegen unbeliebt zu machen.

Wenn der Quellcode/die VCS-Kommentare jedoch außerhalb Ihres Unternehmens veröffentlicht werden, möchte Ihr Management möglicherweise eine stärkere Linie einschlagen, da es für Unternehmen schlecht ist, Ihre Kunden zu beleidigen.

5
Stephen C

Eines der Probleme mit der Obszönität ist, dass sie sich von Kultur zu Kultur unterscheidet. In den USA neigen unschuldige Dinge dazu, "durchgebrannt" zu werden, während in anderen Ländern oft dieselbe Sprache in Parlamentsdiskussionen ausgetauscht wird.

Obszönitäten in Bezug auf Code und Commit-Kommentare sind weit verbreitet, wahrscheinlich aufgrund der Ansicht "Niemand wird sie sehen". Ich denke, dass es jetzt tatsächlich üblicher ist, dass die meisten Organisationen Ostereier verbieten.

Ich persönlich denke, dass nicht kundenorientierte Dinge (wie interne Commit-Materialien) kein so großes Problem sind.

Die meisten großen multinationalen Unternehmen werden jedoch von Rechtsabteilungen und "sicheren Arbeitsplätzen" und all diesen Dingen geführt, was bedeutet, dass alles, was für mindestens eine Person anstößig sein könnte, ein Problem und ein potenzieller Grund für die Entlassung ist. Ich gebe es nur ungern zu, aber ich neige dazu, mich den Vorschriften derer zu beugen, die mein Gehalt zahlen.

Eine schnelle Lösung für dieses Problem besteht darin, einen Profanitätsfilter auf Ihrem Versionsverwaltungssystem zu installieren (als Presubmit-Skript oder als regelmäßige Überprüfung).

5
Uri

Ich denke, es ist in Ordnung, solange es nicht außer Kontrolle gerät, als würde man dort Bomben abwerfen. Ich habe einen Mann gesehen, mit dem ich zusammenarbeite und der ein Skript zwischen zwei Charakteren schreibt, in dem die verschiedenen Objekte besprochen werden, die sie jeweils darstellen. Es gab einen mehrzeiligen Kommentar, der ungefähr 30 Zeilen dieser beiden Charaktere umfasste, die miteinander hin und her sprachen.

/ * * igor: soll ich mich zum öffentlichen Masster machen? * Frankenstein: ah igor, ich werde von deinen besten Eigenschaften erben ... * /

So ging es lange weiter. Er hat zwei Objekte namens "Frankenstein" und "Igor" als Teil einer Überprüfung der geistigen Gesundheit erstellt. Es war eigentlich sehr kreativ, aber eine totale Zeitverschwendung. Ich hätte lieber ein paar WTFs oder Expletives gesehen als ein Drehbuch zwischen zwei C # -Objekten ...

3

Hängt von der Kultur des Unternehmens/Kunden ab. Wenn Sie beispielsweise Bibelsoftware entwickeln, sind Sprengsätze in jeglicher Form definitiv unerwünscht. Auf der anderen Seite könnte es einem Spieleentwickler nicht so viel ausmachen (oder zum anderen Extrem gehen).

Ich bin immer der Meinung, dass Kommentare (in Code oder Commits) hilfreich sein sollten. Bestimmte Wörter erregen unsere Aufmerksamkeit mehr als andere - Sprengsätze, sogar die weiche Sorte, werden definitiv bemerkt. Es kann nützlich sein, auf etwas aufmerksam zu machen, das einfach falsch ist, aber Sie haben noch keinen Weg daran vorbei.

Das heißt, ich benutze keine Sprengstoffe, aber ich werde gelegentlich Dinge wie "Doh!" oder "Huh?" das ist nicht zu unterschiedlich im Geist. Wenn es Sie stört, sprechen Sie mit dem Täter darüber, der möglicherweise nicht darüber nachdenkt. Wenn Sie aufgefordert werden, eine Wanderung zu unternehmen, und Sie sich stark dafür fühlen, rufen Sie den Manager an. Wenn Sie keine Unterstützung vom Manager erhalten, müssen Sie lernen, damit zu leben oder woanders hinzugehen.

2
Berin Loritsch

Wie andere gesagt haben, hängt es vom Arbeitsplatz ab und wer den Quellcode sieht.

Wenn ich den Quellcode verkaufen würde, hätte ich ein zweites Repository mit nur freigegebenen Versionen und würde dort keinen Check-in-Kommentar zulassen, außer einer Beschreibung dessen, was jede neue Version bietet. Was ich jeden Tag mache und all meine Fehltritte sind zwischen mir und meinem Team, nicht zwischen meinen Kunden.

Derzeit meldet mein Build-Server OMG-, WTF-, Kludge-, Mess- und TODO-Kommentare als Metrik für die verbleibende Bereinigung, damit sie jetzt Teil des Prozesses sind.

1
Bill

Wenn Sie in Open-Source-Software Schimpfwörter sehen und diese loswerden möchten, bereiten Sie sich auf die Möglichkeit eines Push-Backs vor. Schreiben Sie nicht einfach einen dreizeiligen Fehlerbericht und erwarten Sie, dass er akzeptiert wird. Schreiben Sie einen Mini-Aufsatz, in dem erklärt wird, warum Obszönitäten und diskriminierende Sprache schlecht sind, und gehen Sie den Widerlegungen vor.

1
Andrew Grimm

Nun, ich bin mir nicht ganz sicher, was Sie sonst noch zu Code wie diesem sagen sollen:

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

Dieser Code wurde aus einer echten, extrem muffigen Codebasis gezogen, die ich in letzter Zeit zu optimieren versucht habe. (Der Code ist Open Source, daher verrate ich hier keine Geheimnisse des Arbeitgebers oder so etwas.)

1
dsimcha

Ich denke, es ist eine Frage der persönlichen Präferenz. Das Zeug stört mich nicht wirklich, also würde ich es wahrscheinlich verlassen. Könnte mir sogar einen Hinweis geben, wo sich die Problembereiche im Code befinden.

Stören sie Sie? Aufgrund der Tatsache, dass Sie diese Frage stellen, vermute ich, dass sie es tun. Entfernen Sie sie in diesem Fall oder bereinigen Sie sie in angemessenere Kommentare zu den Fehlern.

0
Marcie