Wie kann man herausfinden, ob Rechtschreibfehler im Quellcode ein ernstes Problem sind oder nicht? [geschlossen]

Ich finde eine sehr beunruhigende Menge an Rechtschreibfehlern in unserer Codebasis, aus der ich ein sehr kurzes, aber repräsentatives Beispiel wiedergeben werde:

ArgumnetCount
Timeount
Gor message from queue 

Leider ist dies keineswegs auf eine Person beschränkt. Es gibt viele nicht-englische Muttersprachler in unserem Team, die dazu beitragen. Ich kann jedoch auch einige der schlimmsten Rechtschreibfehler für unseren amerikanischen, geborenen und aufgewachsenen Software-Architekten feststellen.

Diese finden Sie auch in E-Mails, Präsentationen, Dokumenten und allen schriftlichen Informationen, die wir in einem Softwareentwicklungsunternehmen haben.

Ich möchte wissen, wie ich herausfinden kann, ob es sich um ein ernstes Problem handelt oder nicht.

_{Ich bin diesen Rechtschreibfehlern immer mit Sorge begegnet, aber meine persönliche, offizielle Politik lautet, dass wir nicht dafür bezahlt werden, Dinge richtig zu buchstabieren , sondern dafür, Dinge zu erledigen. Deshalb habe ich im Unternehmen nie wirklich jemanden dafür kritisiert. Aber ich habe dieses Problem bei einigen meiner engen Freunde angesprochen und es nie endgültig geklärt.}

Rechtschreibfehler können eines von zwei Dingen bedeuten:

• Die Person, die sie herstellt, spricht kein Englisch und nimmt sich nicht die Zeit, dies durch die Verwendung geeigneter Tools (Wörterbücher, Rechtschreibprüfungen usw.) auszugleichen.
• Die Person, die sie herstellt, beherrscht Englisch, kümmert sich aber überhaupt nicht um die Rechtschreibung.

Beides ist ein ziemlich schlechtes Zeichen, da es bedeutet, dass die betreffende Person keine Lesbarkeit, Wartbarkeit und Eleganz auf ihrer Prioritätenliste hat. Wenn die Ursache eine mangelnde Beherrschung der englischen Sprache ist, bedeutet dies auch, dass der Person zwei wesentliche Fähigkeiten fehlen - schriftliche englische Kommunikation und ein allgemeines Gefühl für Sprachen (wenn Sie Ihre Gedanken nicht klar auf Englisch ausdrücken können, besteht die Möglichkeit, dass Sie es können). Sie lassen sich auch nicht gut in einer Programmiersprache ausdrücken.

Aber warum genau sind Rechtschreibfehler schlecht, wenn alle anderen gleich sind? Schließlich funktioniert der Code und es ist dem Compiler egal, wie Sie Ihre Bezeichner benennen, solange sie nicht gegen die Syntaxregeln verstoßen. Der Grund ist, dass wir Code nicht nur für Computer, sondern vor allem auch für Menschen schreiben. Wenn das nicht der Fall wäre, würden wir immer noch Assembly verwenden. Quellcode wird einmal geschrieben, aber während seines Lebenszyklus hunderte Male gelesen. Rechtschreibfehler erschweren das Lesen und Verstehen des Quellcodes. Leichte Fehler führen dazu, dass der Leser für den Bruchteil einer Sekunde stolpert. Viele von ihnen können erhebliche Verzögerungen verursachen. wirklich schlimme Fehler können den Quellcode völlig unlesbar machen. Es gibt ein weiteres Problem: Der größte Teil des Codes, den Sie schreiben, wird von einem anderen Code referenziert, und dieser Code wird häufig von einer anderen Person geschrieben. Wenn Sie Ihre Bezeichner falsch schreiben, muss sich eine andere Person nicht nur merken (oder nachsehen), wie der Name lautet, sondern auch, wie genau er falsch geschrieben ist. Dies braucht Zeit und unterbricht den Programmierfluss. und da der meiste Code während der Wartung mehr als einmal berührt wird, verursacht jeder Rechtschreibfehler eine ganze Reihe von Unterbrechungen.

Überlegen Sie, wie Entwicklerzeit gleich Gehalt gleich Ausgaben ist. Ich denke, es sollte einfach genug sein, dies zu erklären. Schließlich kann es bis zu 15 Minuten dauern, bis der Fluss unterbrochen und wieder aufgenommen wird. Auf diese Weise kann ein schwerwiegender Rechtschreibfehler leicht einige hundert Dollar für die Weiterentwicklung und Wartung kosten (aber es handelt sich um indirekte Kosten, die in Schätzungen und Bewertungen nicht direkt sichtbar sind und daher vom Management häufig ignoriert werden).

Ich bezweifle tatsächlich, dass "Timeount" eine Frage der Ablehnung von Muttersprachlern ist. Menschen machen Unmengen von Tippfehlern in ihrer Muttersprache. Ich würde diese speziellen Beispiele nicht als "Engrish" bezeichnen.

Trotzdem verstehe ich, dass es nicht um diese speziellen Beispiele geht. Ich stimme Ihnen grundsätzlich zu. Ich bin auf tatsächliche Probleme gestoßen, die durch diese Art von Dingen verursacht wurden ("Wenn es keine Spalte mit dem Namen" Anhänge "gibt, erstelle Anhänge").

Programmierer zu sein bedeutet, präzise und vorsichtig mit Tippfehlern, Kommas, Semikolons und Punkten umzugehen, was die meiste Zeit menschensprachenunabhängig ist.

Wenn Sie zum ersten Mal nach der TimeoutVariablen suchen, um herauszufinden, wie sie geschrieben wurde Timeount, kennen Sie einen weiteren Grund, warum die Rechtschreibung wichtig ist.

Wenn Sie dieses Problem stört, lassen die meisten IDE-Programme jetzt die Rechtschreibprüfung in Kommentaren zu, sodass Legastheniker zumindest so aussehen können, als könnten sie buchstabieren. Es hilft mir sicher! Es ist daher eine triviale "Korrektur", eine gute Rechtschreibung zu haben.

Rechtschreibfehler in öffentlichen Klassennamen und Methoden sind einfach unprofessionell. Sie kosten Zeit und Geld. In statisch typisierten Sprachen wie Java, in denen die IDE ein Menü mit Klassen- und Methodennamen erzeugen kann, sind sie schmerzhaft. Sie sind in dynamisch getippten Sprachen nicht tolerierbar.

Noch schlimmer sind Rechtschreibfehler in Namen von Datenbanktabellen und Spalten.

Nach meiner Erfahrung hängt die korrekte Rechtschreibung nur geringfügig von den Englischkenntnissen des Programmierers ab. Ich habe gesehen, dass englische Muttersprachler Code mit im Wesentlichen zufälligen Schreibweisen und Wortumbrüchen produzieren. Ich habe auch nicht englische Muttersprachler gesehen, die darauf bedacht sind, korrekte Schreibweisen zu erstellen. Die korrekte Schreibweise hängt jedoch stark von der gesamten Codequalität ab. Kompetente Programmierer, egal welche Englischkenntnisse sie haben, legen großen Wert auf die Qualität ihrer Arbeit und gehen mit der Benennung sorgfältig um.

Im Quellcode, in internen Präsentationen und Dokumenten usw. sind kleine Tippfehler, die weder die Bedeutung noch das Verständnis beeinträchtigen, kein Thema. Repariere sie einfach selbst in der Quelle, wenn du sie irritierend findest.

Insbesondere in Kommentaren ist der Stoff wichtiger als die Form. Kein Engrish hier:

String s = "Wikipedia"; / * Weist der Variablen s den Wert "Wikipedia" zu. * /

Tatsache ist, dass manche Menschen von Natur aus vorsichtiger als andere sind (ob dies auf Bildung, Einstellung, Intelligenz oder was auch immer zurückzuführen ist, ist nicht relevant). Wie viel Aufwand zur Behebung dieses Problems ist eine geschäftliche Wertfrage: Erhalten Sie durch die Behebung von Tippfehlern mehr Wert als durch die Behebung von Fehlern? Bei internen Angelegenheiten lautet die Antwort normalerweise nein. Ihre Kunden werden sich nicht über Tippfehler in Ihren Quellcode-Kommentaren beschweren (es sei denn, Sie machen Open Source).

Vorsätzliche Fehleingaben und unangemessene Kommentare sind unprofessionell und sollten vermieden werden. Der Schwerpunkt sollte jedoch auf wichtigen Dingen liegen (z. B. Schaffung von Geschäftswert, wenn Sie für Unternehmen arbeiten).

Öffentlich sichtbare Dinge müssen natürlich sorgfältig gegengelesen werden.

Das Problem hierbei ist nicht der Stich selbst, sondern die mangelnde Klarheit der Kommentare. Perfektes Englisch ist nicht erforderlich, klares Englisch. Es ist trivial, etwas über Google zu starten, um die offensichtlichen Fehler zu finden.

Beispielsweise ist es auf den ersten Blick nicht klar, ob Gor message from queue"eine Nachricht aus der Warteschlange" oder "eine GOR-Nachricht aus der Warteschlange" bedeutet. Sie müssen den Code lesen, um die Bedeutung des Kommentars zu verstehen (wodurch das Objekt des Kommentars besiegt wird).

Sie sollten darum bitten, Codeüberprüfungen in Ihrem Unternehmen durchzuführen. Sie können dann Leute auf konstruktive Weise "kritisieren", während sie Ihnen dasselbe antun.

Es sollte offensichtlich sein, dass der Compiler sich nicht um Rechtschreibfehler kümmert, solange Sie dieselbe Schreibweise verwenden, z. B. wenn Sie auf eine Variable verweisen. Dann stellt sich die Frage, ob Rechtschreibfehler negative Auswirkungen auf die Fähigkeit der Teammitglieder haben, den Code zu pflegen.

Der einzige Weg, den ich sehen kann, um das zu tun, wäre, mit den Leuten zu sprechen, die die Wartung durchführen, und Sie könnten damit beginnen, zu fragen, ob es jemandem schwerer fällt, Code zu folgen, der Rechtschreibfehler enthält.

Ich glaube nicht, dass es eine Möglichkeit gibt, die Subjektivität vollständig von diesem Problem zu entfernen, aber um es zu reduzieren, können Sie (manuell oder über ein Skript) die Quelle durchsuchen, um eine geschätzte Anzahl von Rechtschreibfehlern für ein bestimmtes Codemodul zu ermitteln und festzustellen, ob Wartungsarbeiten durchgeführt wurden Bei den Modulen mit einer höheren Anzahl von Rechtschreibfehlern dauerte es im Durchschnitt länger als bei den Modulen mit weniger Rechtschreibfehlern.

Natürlich sind nicht alle Module gleich, daher können Sie überlegen, ob Sie Ihre Ergebnisse mit verschiedenen Metriken wie der zyklomatischen Komplexität des Moduls gewichten möchten.

Nach meiner Erfahrung sind solche grundlegenden Rechtschreibfehler beunruhigend und können für tiefere Probleme symptomatisch sein. Jedes Projekt , das ich gearbeitet habe mit „trivial“ Fehlern wie das hatte echte Probleme in Design , dass es irgendwie durch den Review - Prozess gemacht nur während der Entwicklung auftauchen zu, das ist nicht , wenn Sie herausfinden mögen , dass die kritischen Funktionen , die Sie wirklich brauchen ist nicht da

Ich würde die Spezifikationen für das System (falls vorhanden) noch einmal überprüfen und das Gesamtdesign untersuchen. Es würde mich nicht wundern, wenn Sie Löcher finden würden.

Dies sind eigentlich zwei getrennte, aber verwandte Probleme. Es hängt davon ab, wo die Rechtschreibfehler sind:

1) Im Quellcode. Wenn Sie eine Kennung wie ArgumnetCounthaben, kann dies zu echten Problemen führen, wenn jemand mit der richtigen Schreibweise vorbeikommt. Daher sollten Sie diese Fehler nach Möglichkeit beheben. Wenn Sie die Abwärts-API-Kompatibilität beibehalten möchten, können Sie Folgendes tun:

/**
 * @deprecated - use setArgumentCount()
 */
public void setArgumnetCount(int c) {
    setArgumentCount(c);
}

2) In lesbarem Text (E-Mails, Dokumentation, Codekommentare). Das richtige Schreiben ist wichtig, aber ich würde sagen, es hat eine geringere Priorität, da die Parsing-Software in Ihrem Kopf viel verzeihender ist. Wenn Sie einen Text mit einigen Fehlern sehen, der immer noch lesbar ist, machen Sie sich keine Sorgen - das ist nicht Ihr Problem. Aber wenn jemand Ihnen einen freien assoziativen Unsinn schickt und erwartet, dass Sie diesen Unsinn als Vorlage für eine Mehrbenutzer-Webanwendung verwenden, sollten Sie dem Autor eine höfliche Notiz mit der Bitte um Klärung senden (so etwas wie: "Sie Analphabet, wie geht das?" Erwarten Sie, dass ich diese Scheiße verstehe? ")

Korrektes Rechtschreib-Englisch ist ein Muss im Code. Ich habe auch eine große Codebasis voller Kauderwelsch darin und es ist ein Albtraum, den es zu bewahren gilt.

Lass das nicht außer Kontrolle geraten. Versuchen Sie, alle darüber zu informieren, dass die Programmierer keine Gedankenleser sind.

Nun, das ist ein vielseitiges kulturelles Problem.

Aus deutscher Sicht: Wir bemerken, wie unsere eigene Sprache immer mehr von englischen Begriffen beeinflusst wird. Dies gilt bis zu nationalen Unternehmen mit englischen Slogans oder Werbung. Einige Leute, vor allem in Führungspositionen, können offenbar nur einen Satz im Klartext aussprechen. Ihre Rede ist voller Schlagworte und unverständlichem Management-Slang. Wir sagen, solche Personen sprechen "denglisch".

In Anbetracht dieser Sachlage und der Tatsache, dass Englisch die "Verkehrssprache" insbesondere im Softwaregeschäft ist, ist es unvermeidlich, dass Englisch selbst durch die große Anzahl von Nicht-Muttersprachlern beeinflusst wird. Aber für englische Muttersprachler ist dies immer noch besser, als Chinesisch lernen zu müssen, um an der SW-Industrie teilzunehmen.

Ist es Farbe oder Farbe? Wessen englische Version ist Ihrer Meinung nach die richtige? Die korrekte Schreibweise eines Mannes ist die Entschuldigung eines anderen Mannes, um einen gewinnbaren Krieg zu beginnen.

Wenn Sie einen Krieg beginnen möchten, wählen Sie Ihre Schlachten sorgfältig aus und gewinnen Sie sie. Machen Sie sich in Ihrem Fall keine Gedanken über Kommentare, machen Sie sich weniger Gedanken über Interna und konzentrieren Sie sich (fast) ausschließlich auf APIs

Ich habe eine Maxime: Ordentlicher Code bedeutet nicht unbedingt einen ordentlichen Verstand, aber das Gegenteil ist sicherlich wahr: unordentlicher Code, unordentlicher Verstand.

Ein Programmierer, der sich nicht die Zeit nimmt, Variablen richtig zu benennen und Kommentare richtig zu schreiben, nimmt sich mit ziemlicher Sicherheit nicht die Zeit, etwas anderes richtig zu machen. Ob der Programmierer englischer Muttersprache ist, ist keine wirkliche Frage, da Probleme mit seinem Englisch bei der Begutachtung durch Fachkollegen angegangen werden können (und sollten).

Ja, es ist ein ernstes Problem für das Produkt, für das Team und für die Einzelpersonen.

• Für das Produkt: Die Korrektur kann zu Fehlern führen, die nur vom Kunden festgestellt werden
• Für das Team: Das Team verbringt viel Zeit damit, fehlerhafte Codierungen zu korrigieren, anstatt Wert zu schaffen
• Für den Einzelnen: Falsche Schreibweise lässt Sie dumm aussehen und mindert Ihre berufliche Stellung unter Ihren Kollegen.