Umgang mit Profanität im Quellcode [geschlossen]

Wie gehen die Leute mit Obszönitäten in Quellcode- und 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 muss?

Es sollte vorsichtig abgeraten werden

..sie können unmöglich wissen, wer den Quellcode im Laufe seiner Lebensdauer sehen wird.

Während es Teil der Arbeit ist, sich mit einem besonders komplexen oder alten Teil des Codes zu ärgern und sich darüber lustig zu machen, ist es sowohl unprofessionell als auch unprofessionell, Expletive / Rants / ASCII-Kunst / schlechte Witze / anstößige Bemerkungen in den Quellcode einzufügen schlechte idee meiner erfahrung nach. 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 gesehen habe:

• Eine hohe Anzahl von Expletiven in Code, der als Open-Source- / Beispielcode für die Öffentlichkeit freigegeben wurde.
• Scherze mit schlechtem Geschmack, die einige Teammitglieder zutiefst beleidigen und ein Arbeitsgericht zur Folge haben.
• Wegwerfbemerkungen, die tatsächlich rassistisch / sexistisch / geschlechtsspezifisch waren, haben dazu geführt, dass Menschen gefeuert wurden.

Obwohl wir alle ein paar Outlets für Frust / Spaß / Japing brauchen, ist der Quellcode nicht der richtige Ort, um dies zu tun, IMO. Sie würden keine expliziten / witzigen / anstößigen Kommentare in einen Vertrag, eine Hilfeseite, eine Blaupause oder ein anderes professionelles Dokument einfügen, auch wenn diese Dokumente möglicherweise noch seltener als der Quellcode gelesen werden.

Wenn die Teamleiter mit aller Gewalt dagegen vorgehen, wird es ärgerlich, also sage ich mit einem leisen Wort an die Problemingenieure: "Vorsichtig entmutigt" und stelle geeignete Entlüftungsmechanismen bereit, um Dampf abzulassen, sei es Facebook oder Instant Messaging , Airhockey oder 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 "nicht" nicht kannte - er vermisste die Buchstaben o, l und d - und einen Großteil seines Codes mit ausführlichen Erklärungen darüber gespickt hatte, wie er nicht konnte Bringen Sie X zur Arbeit, weil die Person Y das Problem Z verursacht hat. Sein Code war großartig. seine Rechtschreibung war nicht so gut. Es genügt zu sagen, dass jeder nachfolgende Rezensent dieses Codes (z. B. ich) alarmiert war, eine große Anzahl zufälliger Flüche im Code zu sehen. Ein Teil dieses Codes wurde Partnern (Treiberschreibern) gezeigt. Stellen Sie sich ihren Schrecken vor, die Flüche zu sehen. Die Beschwerden sollten idealerweise mündlich an den Projektmanager gerichtet sein (in diesem Fall kann Person Y in die Diskussion einbezogen werden) oder möglicherweise Nachrichten übermitteln, 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 sie lesen könnte. Dies war in Ordnung, bis Babelfish / Google Translate eine Option für 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 hat sich ein Typ wirklich mit ASCII-Kunst beschäftigt und alle Arten von Kunst in seinen Quellcode gesteckt, ungepunktet (oder vielleicht gesegnet) von Code-Reviewern. Nach einer Weile hielt er sich aus irgendeinem Grund an Drachen auf, normalerweise mit einer Art Slogan. Später trat eine walisische Person dem Team bei. Das nationale Wahrzeichen von Wales ist ein roter Drache, daher war der Neue anfangs fröhlich über die Bilder, aber dann beleidigt, als einige der albernen Umbauten als anstößig aufgefasst werden konnten. Ja, eine Vermittlung durch einen Teamleiter ist erforderlich, aber das hätte nicht passieren dürfen.

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

Wenn Sie Ihren Quellcode verkaufen (dh Sie sind ein Komponentenschreiber), sollte er wahrscheinlich nicht dabei sein.

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

Wenn Sie jemanden sehen, der viele WTFs schreibt, ist dies vielleicht ein Zeichen, 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 ganz andere Situation zu bewältigen. Vielleicht haben sie eine berechtigte Beschwerde und wissen nicht, wie man sie richtig ausspricht. 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 sagt Ihnen viel darüber aus, wie die Dinge laufen.

Ich arbeite für ein Fortune 500-Unternehmen, das Konsumgüter entwirft, herstellt und vertreibt, deren µController selbst entwickelten Code ausführen. Rechtsstreitigkeiten sind immer möglich, entweder von Verbrauchern, die schnell reich werden möchten, oder von Wettbewerbern, die Verstöße geltend machen. Aus diesem Grund schreiben wir unseren Code und ALLE Kommentare mit dem Wissen, dass er (wahrscheinlich) irgendwann von feindlichen Geschworenen geprüft wird. Das bedeutet, dass Variablen- und Funktionsnamen keine anstößigen Begriffe enthalten sollten, wie z KILL_CHILD(int process_id). Während der Zweck dieser Beispielfunktion durchaus darin bestehen könnte, untergeordnete Prozesse zu beenden, wie würde eine feindliche Jury diesen Funktionsnamen anzeigen, 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 erklären könnte, was ein untergeordneter Prozess ist (aus dem vorherigen Beispiel) und warum er möglicherweise abgebrochen werden muss, wäre es nahezu 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.

Off-Hand-Kommentare wie diese waren ausschlaggebend für echte 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 Nachrichtenquellen aus der Technologie "SATAN Unleashed On The Internet" berichteten ?

<rant_mode_off>

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

Wenn es dich stört und du der Chef bist, verstehe ich nicht, warum du keine Regel dazu implementieren konntest. Sie sind in dieser hypothetischen Situation immerhin der Anführer.

Wenn es Sie jedoch nur stört und niemand anderes etwas dagegen zu haben scheint, sollten Sie es einfach aufsaugen.

Ich bin vielleicht nicht der richtige Ansprechpartner, da ich oft leichte Profanität benutze.

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

Wenn ich für eine Anzug-und-Krawatten-Firma programmiere, würde ich versuchen, überhaupt keine Schimpfwörter 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 Leute viel mehr PC (oder Stuck-up) sind als in den Niederlanden, wo ich lebe und arbeite.

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

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. Das heißt, die Codebasis spiegelt in der Regel die allgemeine Professionalität der Gruppe wider, sodass eine explizite Codebasis eine unprofessionelle Gruppe widerspiegeln kann und möglicherweise eine Besprechung stattfinden muss, um der Gruppe "etwas Glanz zu verleihen". Wenn bestimmte Trends im Code angezeigt werden, kann dies ein Hinweis auf allgemeine Probleme innerhalb der Gruppe sein, die behoben werden müssen (dh 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 sicher zu gehen, 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.

Ist das unprofessionell, anstößig oder etwas, das man abschütteln muss?

Möglicherweise alle drei ... je nach Sichtweise.

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

Wenn ich Sie wäre, würde ich es abschütteln, wenn Sie nicht gewillt wären, sich bei Ihren 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 verfolgen, da es für das Unternehmen schlecht ist, Ihre Kunden zu beleidigen.

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

Profanität in Code- und Commit-Kommentaren ist 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 Dinge, die nicht mit Kundenkontakt zu tun haben (wie z. B. interne Commit-Materialien), kein so großes Problem darstellen.

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 möglicher Grund für die Entlassung ist. Ich gebe es nicht gern zu, aber ich neige dazu, mich den Vorschriften derer zu beugen, die mein Gehalt zahlen.

Eine schnelle Lösung für dieses Problem ist die Installation eines Profanitätsfilters in Ihrem Versionsverwaltungssystem (als Presubmit-Skript oder als regelmäßige Überprüfung).

Ich denke, es ist in Ordnung, solange es nicht außer Kontrolle gerät, als würde man dort Bomben abwerfen. Ich habe gesehen, wie ein Mann, mit dem ich arbeite, ein Drehbuch zwischen zwei Charakteren geschrieben hat, in dem die verschiedenen Objekte besprochen werden, die sie jeweils darstellen. Es gab einen mehrzeiligen Kommentar, der etwa 30 Zeilen dieser beiden Zeichen umfasste, die miteinander sprachen.

/ * * igor: soll ich mich öffentlich masster machen? * Frankenstein: Ah igor, ich werde von deinen besten Eigenschaften erben ... * /

So ging es lange Zeit weiter. Er erschuf zwei Objekte, die er nannte, du hast es erraten: Frankenstein und Igor als Teil einer Vernunftsprüfung. 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 ...

Hängt von der Kultur des Unternehmens / Kunden ab. Wenn Sie zum Beispiel Bibelsoftware entwickeln, sind Expletive in jeglicher Form definitiv unerwünscht. Auf der anderen Seite ist es einem Spieleentwickler vielleicht nicht so wichtig (oder er geht ins andere Extrem).

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 sanfte Abwechslung, werden definitiv bemerkt. Es kann nützlich sein, die Aufmerksamkeit auf etwas zu lenken, das einfach falsch ist, an dem man aber noch keinen Weg hat.

Das heißt, ich benutze keine Sprengsätze, 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 - er / sie denkt möglicherweise nicht darüber nach. Wenn sie Ihnen sagen, dass Sie eine Wanderung unternehmen sollen 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 gehen Sie woanders hin.

Nun, ich bin mir nicht ganz sicher, was Sie sonst noch über Code wie diesen sagen sollen:

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

Dieser Code stammt aus einer echten, extrem krummen Codebasis, die ich in letzter Zeit zu optimieren versucht habe. (Der Code ist Open Source, daher verrate ich hier keine Geheimnisse des Arbeitgebers.)

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

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

Derzeit sind meine Build-Server-Berichte zu OMG-, WTF-, Kludge-, Mess- und TODO-Kommentaren Teil des Prozesses.

Wenn Sie in Open-Source-Software Profanität 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 kleinen Aufsatz, in dem Sie erklären, warum Profanität und diskriminierende Sprache schlecht sind, und lassen Sie die Widerlegungen außer Acht.

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 dich ? Aus der Tatsache, dass Sie diese Frage stellen, schätze ich, dass sie es tun. In diesem Fall entfernen Sie sie oder bereinigen Sie sie in angemesseneren Kommentaren zu den Fehlern.