Es gibt verschiedene Codierungsstandards, die bei Softwareunternehmen durchgesetzt werden und das Ziel haben, die Codezuverlässigkeit, Portabilität und vor allem die Lesbarkeit von Code zu verbessern, der von verschiedenen Entwicklern gemeinsam geschrieben wurde.

Zwei bemerkenswerte Beispiele sind der MISRA C- und der C ++ - Standard, die für das JSF-Projekt entwickelt wurden .

Diese haben normalerweise die folgende Form, nachdem sorgfältig festgelegt wurde, was die Wörter "muss", "soll", "sollte", "könnte" usw. bedeuten:

Beispiel:

Regel 50: Gleitkommavariablen dürfen nicht auf exakte Gleichheit oder Ungleichheit geprüft werden.

Begründung: Da Gleitkommazahlen Rundungs- und Kürzungsfehlern unterliegen, wird möglicherweise keine exakte Gleichheit erreicht, selbst wenn dies erwartet wird.

Diese Codierungsstandards stellen normalerweise Beschränkungen für Code dar, die aus Sicht des Compilers legal wären, aber gefährlich oder unlesbar sind und daher als "schädlich" eingestuft werden.

Lasst uns das jetzt missbrauchen!

Sie werden als Mitglied eines kleinen Standardisierungskomitees in Ihrem Unternehmen aufgenommen, das die neuen Codierungsstandards entwerfen soll, die jeder Entwickler im Unternehmen verwenden muss. Unbekannt für die anderen sind Sie heimlich bei einer finsteren Organisation beschäftigt und haben es sich zur Aufgabe gemacht, das Unternehmen zu sabotieren. Sie müssen einen oder mehrere Einträge für den Codierungsstandard vorschlagen, was die Entwickler später behindern wird. Sie müssen jedoch darauf achten, dass dies nicht sofort offensichtlich wird, da Sie sonst riskieren, dass es nicht in den Standard aufgenommen wird.

Mit anderen Worten, Sie müssen Regeln in den Kodierungsstandard einführen, die legitim aussehen und eine gute Chance haben, von den anderen Ausschussmitgliedern akzeptiert zu werden. Nachdem die Projekte gestartet wurden und unzählige Arbeitsstunden in den Code investiert wurden, sollten Sie in der Lage sein, diese Regeln zu missbrauchen (z. B. durch eine technische oder eine sehr technische Regel)wörtliche Auslegung), um ansonsten normalen und qualitativ guten Code als gegen den Standard zu kennzeichnen. Sie müssen sich also viel Mühe geben, um es neu zu gestalten, und die Regeln werden sie von nun an behindern. Da die Regeln jedoch schon seit geraumer Zeit aktiv sind, werden diese Rollen durch reine Dynamik am Leben erhalten und es gibt erhebliche Konflikte Aufgrund von Interessen zwischen verschiedenen Führungsebenen werden die anderen Manager die Regeln wahrscheinlich am Leben erhalten (es wäre töricht, wenn sie ihren Fehler eingestehen würden!), wodurch das Unternehmen behindert wird! Mwahahahahaaa!

Wertung

Die Antwort mit der höchsten Bewertung nach ungefähr 2 Wochen ab dem ersten gültigen Eintrag gewinnt. Ich habe eine Idee für eine gute Antwort, aber ich werde sie erst ein paar Tage später veröffentlichen, da jemand anderes auf die gleiche Idee kommen könnte und ich möchte ihm nicht das Vergnügen rauben. Natürlich wird meine eigene Antwort unabhängig von der Punktzahl nicht über jede andere akzeptiert.

Die Wähler werden aufgefordert, die Antworten danach zu bewerten, wie gut die Lücken verborgen sind und wie frustrierend sie für die Entwickler wären.

Regeln und Vorschriften

• Die Regel oder Regeln müssen wie im obigen Beispiel professionell geschrieben aussehen
• Die Regeln sollten echt aussehen (also werden Dinge wie "Alle Variablen müssen mindestens einen Unterstrich, einen Großbuchstaben, einen Kleinbuchstaben und zwei Zahlen enthalten" nicht akzeptiert. Sie würden Entwickler zwar behindern, aber höchstwahrscheinlich von ihnen nicht akzeptiert der Ausschuss) und wenn ihr Verdienst nicht sofort offensichtlich ist, sollten Sie eine gute Begründung geben.
• Sie sollten in der Lage sein, eine Möglichkeit zu finden, Ihre Regeln zu verwenden / zu missbrauchen, um die Entwickler später zu sabotieren. Sie könnten Unklarheiten in anderen Regeln missbrauchen, oder Sie könnten mehrere Regeln verwenden, die für sich genommen harmlos, aber einmal kombiniert teuflisch sind!
• Sie sollten am Ende Ihres Beitrags eine Erklärung in Spoiler-Tags veröffentlichen, wie Sie die Regeln missbrauchen können
• Die verwendete Sprache darf keine esoterische Sprache sein. Es muss eine Sprache gewählt werden, die in realen Projekten weit verbreitet ist. Daher werden Sprachen mit C-ähnlicher Syntax (anstelle von Dingen wie Golfscript) bevorzugt.

C / C ++

Regel 1: Oktalkonstanten dürfen nicht verwendet werden

Begründung: Oktalkonstanten können Verwirrung stiften. Zum Beispiel könnte ein zufälliger Blick über die Zeile const int coefficients[] = {132, 521, 013, 102};
die Tatsache verfehlen, dass eine der Zahlen im Array in Oktal definiert ist.

Wenn Sie noch böser sein möchten, fügen Sie Folgendes hinzu:

Regel 2: Hexadezimalkonstanten dürfen nur im Rahmen der Bitmanipulation verwendet werden.

Begründung: Wenn eine Konstante einen numerischen Wert darstellt, ist sie besser lesbar, wenn sie dezimal ist. Eine hexadezimale Konstante sollte anzeigen, dass sie eine Bitmaske und keinen numerischen Wert darstellt.

Wie es missbraucht werden kann:

Nehmen Sie das folgende einfache Programm, das die ersten 10 Elemente eines Arrays hinzufügt. Dieser Code wäre nicht standardkonform.

sum = 0;
for (i = 0; i < 10; i++) 
{
    sum += array[i];
}

Beachten Sie, dass dies 0per Definition eine oktale Konstante ist. Gemäß Regel 1 ist es frustrierend, dass der gesamte Code mit 0x00 beschrieben wird. Per Regel 2 noch frustrierender.

Python

Regel 1: Der gesamte Code muss mit dem -OOFlag bytekompiliert werden , wodurch der Bytecode optimiert wird. Wir wollen optimierten Bytecode für Größe und Effizienz!

Regel 2: Tests müssen mit demselben "Artefakt" des Codes ausgeführt werden, der in die Produktion aufgenommen wird. Unsere Wirtschaftsprüfer verlangen dies.

Mit werden Anweisungen -OOentfernt assert. In Kombination mit Regel 2 ist die Verwendung von assertAnweisungen in Tests effektiv verboten . Habe Spaß!

Dies ist für ein Node.JS-Projekt.

Abschnitt 3 - Geschwindigkeit und Effizienz sind von wesentlicher Bedeutung

Regel 3.1: Dateien sollten maximal 1 KB groß sein. Das Parsen größerer Dateien dauert zu lange.

Regel 3.2: Verschachteln Sie Funktionen nicht tiefer als 3 Ebenen. Die V8-Engine muss viele Variablen im Auge behalten, und solche Tiefenverschlüsse erschweren die Arbeit und verlangsamen die allgemeine Interpretation.

Regel 3.3:require() Runarounds vermeiden .

Regel 3.3.1: Alle Module require()d sollten nicht require()tiefer als 3 sein. Tiefrequire() Ketten sind sowohl im Hinblick auf die Speichernutzung als auch auf die Geschwindigkeit teuer.

Regel 3.3.2: Kernmodule zählen als ein einzelnes Modul require(), unabhängig davon, wie oft sie require()intern verwendet werden.

Regel 3.3.3: Externe Module zählen maximal 2require() s. Wir können uns nicht die gleiche Nachsicht leisten wie bei Kernmodulen, können aber davon ausgehen, dass Modulautoren effizienten Code schreiben.

Regel 3.4: Vermeiden Sie um jeden Preis synchrone Anrufe. Diese dauern oft lange und blockieren die Fortsetzung der gesamten Ereignisschleife.

Wie es missbraucht werden kann:

Regeln 3.1 und 3.3 funktionieren nicht gut zusammen. Wenn Sie maximal 1 kb und 3 require()s in der Kette belassen , werden Sie kaum Erfolg haben.
Regeln 3.2 und 3.4 sind nahezu inkompatibel. 3.4 verbietet synchrone Anrufe; 3.2 erschwert die erweiterte asynchrone Arbeit, indem die Anzahl der Rückrufe begrenzt wird.
Regel 3.4 ist, ganz ehrlich, eine Regel, die man in Wirklichkeit befolgen sollte. 3.1, 3.2 und 3.3 sind vollständige Fälschungen.

JavaScript (ECMAScript)

7.3.2: Literale mit regulären Ausdrücken

Literale mit regulären Ausdrücken dürfen nicht verwendet werden. Insbesondere darf der Quellcode keine Teilzeichenfolge enthalten, die mit dem unten definierten Nicht- Terminal "RegularExpression" übereinstimmt .

RegularExpression     :: '/' RegularExpressionBody '/'
RegularExpressionBody :: [empty]
                         RegularExpressionBody [any-but-'/']

[leer] stimmt mit der leeren Zeichenfolge überein und [beliebig - '/'] stimmt mit einer Zeichenfolge mit Ausnahme der Zeichenfolge mit '/' (Schrägstrich U+002F) überein .

Begründung

Aus Gründen der Lesbarkeit wird von regulären Ausdrücken häufig abgeraten. Es ist oft einfacher, Code mit herkömmlichen Zeichenfolgenoperationen zu verstehen, als auf reguläre Ausdrücke zurückzugreifen. Noch wichtiger ist jedoch, dass viele reguläre Ausdrucksmodule eine unterdurchschnittliche Leistung bieten. Reguläre Ausdrücke wurden auch mit Sicherheitsproblemen im Zusammenhang mit JavaScript in Verbindung gebracht.

Allerdings erkennt die Organisation ™ , dass reguläre Ausdrücke gelegentlich ist das beste Werkzeug für den Job. Daher ist das RegExpObjekt selbst nicht verboten.

(Die Syntax des Grammatikauszuges selbst [nicht die, die er definiert] entspricht der der ECMAScript-Spezifikation. Dies würde natürlich an einer anderen Stelle der hypothetischen Spezifikation strenger definiert.)

Der Trick

Das folgende Programm ist nicht konform:

// sgn(x) is -1 if x < 0, +1 if x > 0, and 0 if x = 0.
function sgn(x) {
  return x > 0?  +1
       : x < 0?  -1
       :          0
}

Die oben angegebenen Produktionen für das RegularExpressionBody- Nichtterminal zeigen eine übliche Art, Listen in BNF auszudrücken, indem explizite Rekursionen verwendet werden. Der Trick dabei ist, dass ich die leere Zeichenfolge "versehentlich" als RegularExpressionBody zulasse , sodass die Zeichenfolge //im Quellcode verboten ist. Aber wer braucht schon einzeilige Kommentare? C89 und CSS scheinen in Ordnung zu sein, wenn sie nur Blockkommentare zulassen /* */.

C #

12.1 Statische Methoden, die sich auf den Programmstatus auswirken, sind verboten

Dies liegt daran, dass es schwierig ist, die Ergebnisse einer statischen Methode, insbesondere einer Methode, die einen bestimmten Zustand ändert, zuverlässig zu testen.

12.2 Statische Methoden müssen deterministisch sein

Wenn die statische Methode eine Eingabe entgegennimmt und eine Ausgabe liefert, muss das Ergebnis jedes Mal gleich sein, wenn die statische Methode mit derselben Eingabe aufgerufen wird.

Warum

Der Einstiegspunkt für ein C # -Programm ist die private statische Methode 'main'. Nach der ersten Regel ist dies jetzt verboten, da die Regel vergisst, dass nur öffentliche, geschützte oder interne Methoden dieser Regel folgen sollen. Wenn das Testen wirklich das Problem ist, sollten nur öffentliche Methoden Regel 1 befolgen. Main verstößt möglicherweise auch gegen Regel 2, da das Programm einen Fehlercode ausgibt, wenn das Programm fehlschlägt. Dies kann unabhängig von den Eingabeparametern auftreten. Beispielsweise kann das Programm möglicherweise keine Datei finden oder Abhängigkeiten von anderen Systemen aufweisen, die nicht ordnungsgemäß eingerichtet sind.

JAVA / FRÜHLING

4.2 Verwendung von Reflection im Produktionscode

Da Reflection verwendet werden kann, um auf ansonsten eingeschränkte Teile unseres Quellcodes zuzugreifen, ist die Verwendung von Reflection im Produktionscode strengstens untersagt.

Der Trick

Spring verwendet technisch die Reflektion, um die unterstützten Objekte zu instanziieren und zu verwalten. Durch die Durchsetzung dieser Regel müssten alle Spring-Dienstprogramme entfernt werden.

Website-Kodierung

666.13 UTF-8 darf nicht verwendet werden und muss durch UTF-7 ersetzt werden
.

Wie es missbraucht werden kann:

HTML5 lässt UTF-7 ausdrücklich nicht zu. Das bedeutet, dass moderne Browser dies nicht unterstützen. Wenn alle Tests in einem Browser wie IE 11 durchgeführt wurden, wird dies niemand bemerken, bis es zu spät ist.

JavaScript bitweise Operatoren

1.9 Sie dürfen keine Multiplikation, Division oder Bodenbelag verwenden, es sei denn, sie sind wesentlich schneller als ihre bitweisen Gegenstücke. Sie werden durch die bitweisen Operatoren <<, >> bzw. ~~ ersetzt.
Begründung: Die bitweisen Operatoren sind effizienter.

Wie es missbraucht werden kann:

Die Verwendung von << oder >> anstelle von Multiplikation oder Division führt zu Problemen beim Umgang mit großen Zahlen. Außerdem ignorieren sie die Priorität von Operationen und Dezimalstellen. Die Doppeltilde gibt unterschiedliche Werte zurück, wenn Sie eine negative Zahl eingeben.

JavaScript (ECMAScript)

7.3.1: Identifizierungskonventionen

Kennungen unterliegen Einschränkungen, je nachdem, um welche Art von Kennung es sich handelt. Bezeichner werden in die Typen Variable aufgeteilt , Konstante , Funktion und Konstruktor unterteilt . siehe 5.3. Die Einschränkungen sind unten angegeben.

• Variable: Das erste Zeichen muss ein Kleinbuchstabe sein. Kamelkasten (siehe 1.3) sollte verwendet werden, um Wörter innerhalb eines Bezeichners zu trennen.

• Konstante: Der Bezeichner darf nur aus Großbuchstaben und Unterstrichen ('_', U+005F) bestehen. Unterstriche sollten verwendet werden, um Wörter innerhalb eines Bezeichners zu trennen.

• Funktion: Funktionen müssen den gleichen Regeln wie der Bezeichnertyp folgen .

• Konstrukteur: Das erste Zeichen muss ein Großbuchstabe sein. Kamelkasten (siehe 1.3) sollte verwendet werden, um Wörter innerhalb eines Bezeichners zu trennen.

Begründung

Lesbare Bezeichnernamen sind für die Wartbarkeit sehr wichtig. Das Beschränken der Bezeichner auf bekannte Konventionen erleichtert auch den Übergang zwischen verschiedenen Codebasen. Diese besonderen Konventionen sind den Standardkonventionen für die Java ™ -Programmiersprache [1] nachempfunden .

Der Trick

Ich muss dem jQuery-Team leider mitteilen, dass der häufigste Name für das "globale jQuery-Objekt" mit dieser Namenskonvention nicht übereinstimmt. Zum Glück haben sie schon gedacht , und beide bieten $und jQueryals globaler Namen mit Bezug auf das gleiche Objekt. Ich stelle mir vor, dass die Userbasis möglicherweise nicht so sehr darauf aus ist $, von jQueryüberall zu wechseln .