Tick-the-Code Quellcode Beispiele

(Hinweis: Folgender Text benutzt das Wort "Tick" für angekreutzte Markierungen im Quellcode produziert durch "ticken" mit Tick-the-Code.)

MAGIC-Ticks
Sogar null, sogar Initialisierungswerte beinhalten Zauber. Kontextunabhängig müssen Zeichenketten getickt und analysiert werden. Wie aufwändig ist es ein Modul zu übersetzen, wenn die Zeichenketten sich überall bestreut finden? Wenn alle Zeichenketten sich in nur einer Stelle finden, sind viel leichter für Konsistenz zu überprüfen. Konsistenz ist wesentlich für verschiedene Debug-meldungen. Hier sieht man ein hervorragendes Beispiel wie Zaubernummern schwärmen. Die Nummern sind wahrscheinlich verwandt mit anderen Nummern in naheliegendem Code. Wir wissen dass Code muss man ändern. Wie einfach ist es Code dieser Art zu ändern ohne ihn kaputtzumachen? Diese Regel gilt für ALLE buchstäbliche Nummern, Zeichenkonstante und Zeichenketten. Benenn einen konstanten Wert kreativ und bedeutungsvoll. Zauber den nicht einfach aus der Luft in den Code. Mit dieser Regel kannst du zauberhafte Konstante finden. Dann lässt du es für den Autor die Ticks ernst zu nehmen und die richtige Massnahmen zu treffen.
ELSE-Ticks
Hier hat man einen ganz klaren ELSE-Bruch. Vielleicht muss man wirklich nichts tun wenn der boolesche Ausdruck falsch ist, aber der Code behält es geheim. Derjenige der den Code nachpflegen muss, muss annehmen dass der Code richtig ist. Wir alle wissen dass ist nicht immer der Fall. Hier gibt es einen besonders fiesen ELSE-Bruch. Die Einrückung ist eindeutig falsch. Der zweite if ist so eingerückt als ob er ein Teil des oberen if-Blocks wäre. Jedoch fehlen die geschweifte Klammern um jeglichen Block um das zu zeigen. Wenn man diesen Code mit der PTHESES-Regel prüfen würde, hätte man hier zwei Verstöße gefunden. Keinen Zweifel, in diesem else-Abschnitt gibt es keinen Code. Ist das so gemeint oder ist das unabsichtlich? Das kann man nicht mit Sicherheit sagen. Wir können das vom umliegenden Code deduzieren und hoffentlich finden wir eine aktuelle und relevante Anmerkung die die fehlende Teile als unnötig nennt. Sonst haben wir Pech gehabt. Es wäre so leicht den Gedanke "Hier brauchen wir keinen Code, wenn der boolesche Ausdruck falsch ist" aufzuzeichnen. Nur eine Anmerkung wie /* no else */ würde schon eindeutig dem Leser ausdrücken dass der else-Abschnitt überlegt wurde und unnötig gefunden wurde. Wenn wir dieser Angewohnheit folgen würden, müssten wir nur diejenige if-Aussagen verdächtigen, die weder einen else-Abschnitt noch eine noelse-Anmerkung haben.
TAG-Ticks
Dieser TAG-Verstoß ist einfach zu finden, "XXX" zeigt eindeutig zu einem Merkzeichenkommentar. Es will nur gesehen werden. Eine Frage als Anmerkung schreit "UNSICHERHEIT"! Ist der Code korrekt oder nicht? Ist es fertig oder nicht? Hier haben wir einen gefährlichen Punkt. "Vorläufig fest programmiert"? "Vorläufig"? Wann wird das verändert? Bevor die Produktionsversion? Bevor das Jahr ist um? Gestern? Quellcode hat kein Platz für Unsicherheit. Die schlechtesten Programmierer können ihre Unsicherheit meisterhaft verstecken, und das ist eine meisterhafte SCHLIMME Sache. Die die nicht geschickt genug sind, aber ehrlich, schreiben ihre Bedenken in Anmerkungen. Die sind hervorragende Hinweise um Unsicherheit und fehlerhaften Code zu finden. If you tick more code, you'll bump into comments talking about certain compiler versions or mentioning other tool or environmental peculiarities. If the code is old enough, the comments might refer to ancient problems. Their time might have passed by now. Use TAG ticks to analyse these comments and perhaps get rid of ancient crud.
NULL-Ticks
Dieses Beispiel kann schon bekannt sein. Wir haben es bei ELSE-Beispiele gesehen. Ticks bilden gerne Gruppen aus. Es ist wichtig jede Regelverstoß für sich zu ticken und mit dem richtigen Regelnamen klar markieren. Unmarkierte Bedenken verschwinden einfach nicht vom Code. Wenn man NULL-Verstöße sucht, ist 'Release' ein sehr brauchbares Schlüsselwort. Es heißt normalerweise daß irgendwas beendet wurde. Es kann danach Zeiger geben die noch zu dem befreiten Speicherbereich zeigen. Die Zeiger sollte man ungültig machen so das keiner die unabsichtlich benutzt. Heutzutage hat die Regel CLOSURE die NULL-Regel ersetzt. Indem NULL war nur für Zeiger, gilt CLOSURE mehr generell für alle mögliche Enden: eine Datei wird gelöscht, dynamisches Speicher wird befreit, eine Datenbankverbindung wird gebrochen oder ein Socket wird geschlossen.
PTHESES-Ticks
Fehler mögen vielfache arithmetische Operationen. Der Code kann nur klarer werden, wenn man Klammern benutzt um explizit auszudrücken genau in welcher Reihenfolge die Kalkulationen laufen sollten. Das wird sehr wichtig wenn der Code verändert werden muss und man muss zum Beispiel "+ 1" zur Gleichung zufügen. Es gibt einige zauberhafte Nummern in diesem Code (die Regelnamen kann man nicht sehen, nur die purpurnen Kreise). Es gibt aber auch verschiedene Operatoren: "&", "<<" und sogar ein paar Klammern. Ich behaupte daß einige fehlen noch. Man könnte natürlich die Operatorpräzedenz nachprüfen, aber warum sollte man sich bemühen? Warum nicht einfach die gemeinte Präzedenz mit Klammern explizit machen? Was würde man verlieren? Nur ein paar Bugs, denke ich. Laut Wörterbuch heißt "explizit" "etwas ausdrücklich und deutlich zu definieren so daß auch die Details genannt werden, so daß keine Unklarheiten oder Zweifel bleiben." So sollte Quellcode sein. Explizit. Quellcode muss alles ausdrücklich und deutlich definieren so, daß auch die Details genannt werden so, daß keine Unklarheiten oder Zweifel bleiben.
CALL-Ticks
Diese zwei Zeilen scheinen zusammen zu gehören. In vielen Ställen in diesem Beispielcode waren die beide entweder geändert oder gelesen gleichzeitig. Eine Möglichkeit es zu sichern, daß beide Variablen immer gelesen oder gesetzt werden, ist die in eine Routine einzupacken. Einen Mutex zu behandeln scheint ziemlich klar, aber wir haben hier sechs Codezeilen. In diesem Beispielcode werden dieselben sechs Zeilen sogar mehrmals wiederholt. Einen Mutex zu sichern sollte den Code helfen richtig zu laufen, aber man muss nicht immer jedes Detail sehen. Wenn man eine Routine kreiert und die Details versteckt, kann man sich besser auf die wirkliche Sache konzentrieren. Die CALL-Ticks zu interpretieren ist nicht immer ganz so direkt wie die Beispiele zeigen. Manchmal muss man an Abstraktionen auf höheren Ebenen denken und ein CALL-Tick kann eine massive architektonische Reorganisation verursachen. Wenn man merkt, daß die Abstraktionen im Code nicht in Ordnung sind, sollte man die Schuld der CALL-Regel nicht geben. Die Regel hat nur die Bewusstheit erhöht und man merkt die Designfehler besser. Man sollte das Design sowieso verbessern, mit der CALL-Regel oder ohne.

Zuletzt aktualisiert: 9.3.2009.