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

Leave a Comment

Previous post:

Next post: