Coding Guideline Comment 1

by kai on 23/09/2003



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!

{ 3 comments… read them below or add one }

Jens September 23, 2003 at 12:00 am

Wir hälst Du es eigentlich mit der Sprache für Variablen und Kommentare? Ich bringe meine Kollegen regelmäßig zur Weissglut, indem ich durchweg englische Variablennamen nutze und mir auch die Kommentare in Englisch aus den Fingern sauge. Ich find das nur konsequent, allerdings ist bei Englisch die Gefahr immer ein wenig größer, irgendein reserviertes Wort zu erwischen (okay, nicht gerade bei Cold Fusion, aber ab und an blickt man auch mal wieder über den Tellerrand).
Als Agent M noch neben mir saß, durfte ich recht viele Altprojekte bearbeiten, wo englische und deutsche Benamung gemischt benutzt wurde (das aber wenigstens konsequent)… 😉

Reply

Hansjoerg September 24, 2003 at 12:00 am

Über die Strukturen kann man auch sehr schön mit StructKeyExists(scope, varname) prüfen ob ein eintrag existiert – ist angeblich (noch nicht getestet) auch schneller als ein altbekanntes IsDefined.

ad variablenbenennung: da setze ich recht konsequent auf den modus a_[typ]_name, z.B. a_int_recordcount oder z.B. a_struct_users.

Reply

Agent M September 26, 2003 at 12:00 am

@Hansjoerg:

StructKeyExists hat leider einen gravierenden Nachteil: wenn die Struktur, die Du auf Existenz eines Schlüssels überprüfen möchtest, selbst auch nicht existiert, gibt’s eine Fehlermeldung. Ich persönlich präferiere daher ein isDefined().

Reply

Cancel reply

Leave a Comment

Previous post:

Next post: