Coding Guideline Comment 1

Dies ist der Start einer neuen Serie 😉

Ich habe mir – wie in einem der Kommentare zum Eintrag vom 20.09. angekündigt – auf einem Teil meiner Zugfahrt den ersten Teil von Sean Corfields Coding Guidelines für CFMX 6.1 angesehen. Hier meine spontanten aufgescribbelten Kommentare dazu…

Kapitel: “Style: Naming, Comments & Layout”

Ich bevorzuge in bestimmten Architekturen die Nutzung eines Präfixes vor dem Dateinamen. Das hat den Vorteil, dass man am Dateinamen schon relativ klar erkennen kann, welche Aufgabe die Datei erfüllen soll. Wichtig ist das gerade dann, wenn man nach einem MVC-artigen Modell entwickelt:

View:
dsp_user_edit_form.cfm

Controller:
index.cfm
act_insert_user.cfm

Model:
cUser.cfc (Komponenten versehe ich mit einem Präfix “c”, aber das ist nur Geschmackssache. An der Stelle schreibe ich auch immer den zweiten Buchstaben groß)

Zur Dateiplatzierung fällt mir auf, dass Sean vorschlägt, CFCs in einem generellen Ordner “extensions” unterhalb des CFMX-Roots zu lagern und erst darunter beginnt nach Applikation zu unterteilen. Das macht insofern Sinn, als dass man dann einen vernünftigen Pfad in der Dot-Notation hat, der einheitlich ist (extensions.components.{applicationname}) und vor allem die CFCs nicht im Webroot freigibt. Konsequent wäre es dann aber – das ganze folgt ja der Java-Package dot-Notation – mit com.macromedia.extensions.components zu beginnen. Das ist aber nur ein kleines Detail.

Die Variante, Customtags mit CFIMPORT aufzurufen ist ziemlich genial, aber leider viel zu wenig bekannt/ und verbreitet. Gerade wenn man Java kennt und mit JSPs arbeitet, sollte einem dieses Konzept der Notation aber sehr bekannt vorkommen…

Begeistert hat mich Seans Notation für zu evaluierende Variablennamen. Anstelle von variable.varname_#varname# die Struct-Schreibweise variables[“varname_” & index] zu verwenden hat schon was. Von der Optik der Notation mal ganz abgesehen, kann ich mir durchaus nach meinen Erfahrungen mit Structs vorstellen, dass diese Schreibweise auch (minimal) schneller ist. Muss aber noch getestet werden.

Die Verwendung von Boolschen Werten ohne Anführungszeichen macht mega-Sinn, denn so spart CFMX sich die Umwandlung eines Strings (der ja theoretisch auch was total anderes sein könnte) in den internen Datentypen für Boolean (der letztlich auf ein Boolean-Objekt in Java heruntergebrochen wird).

Die Möglichkeit, lokale Variablen im “var”-Scope innerhalb des Tags CFFUNCTION auch mit CFSCRIPT (was ich ja definitiv befürworte) definieren zu können war mir ehrlich gesagt völlig neu, und dabei hatte ich mich schon unzählige Male genau über diese blöde Syntax geärgert, mit der ich gezwungen war, solche Variablen zu Beginn der Funktion mit <cfset var name=”Kai”> zu definieren.

Die Notation der Querynamen halte ich für sehr sinnvoll, aus Gründen der Übersichtlichkeit stelle ich noch ein “q” als Präfix vor, benutze aber auch eine eindeutige Kennzeichnung mit den Schlüsselwörtern Insert, Update, Select und Delete.

Genial ist der Verweis auf das Tool “tidy”. Damit kann man Templates auf Kompatiblität zu HTML und XHTML prüfen. Auch die Vorgabe, 4 Zeichen Einrückung zu verwenden halte ich für sinnvoll, vor allem mit der Bemerkung TAB-zeichen anstelle von Blanks zu verwenden. Allerdings ist mein Argument nicht nur die Dateigröße, sondern vor allem dass es total unkomfortabel ist, wenn man sich mit den Cursortasten beim Navigieren durch zig Blanks kämpfen muss.

Was mir aufgefallen ist: Sean macht keine Vorgabe zur Benennung von Variablen abhängig vom Datentyp. Das setze ich konsequent um und macht das Leben m.E. deutlich einfacher. Beispielsweise präfixe ich alle String-Variablen mit “s”, alle Structures mit “st”, alle Arrays mit “a” etc.

Kommentare zu dem Kommentar erwünscht! 😉 Weitere Kapitel demnächst!