18.3 ActionScript
Codedesign\ActionScript
Ein guter Programmierer zeichnet sich nicht nur dadurch aus, dass er die Grammatik (Syntax) und die Vokabeln (Semantik) der Sprache kennt, sondern dass sein Programmcode nicht nur vom Computer korrekt ausgeführt, sondern auch von menschlichen Lesern nachvollzogen werden kann. Bereits einige wenige Regeln helfen, die Lesbarkeit für Menschen zu verbessern.
18.3.1 Bezeichner
Für die korrekte Wahl der Namen von Eigenschaften und Methoden gibt es unzählige Empfehlungen. Auch hier kommt es in erster Linie wieder darauf an, dass Sie sich aus diesem Fundus an Vorschlägen die für Sie besten heraussuchen.
Als Erstes sollten Sie die Sprache für die Bezeichner und die Kommentare festlegen – in der Hoffnung, dass sich alle Beteiligten daran halten. Für die Bezeichner kommt meist Englisch zum Einsatz, da die Programmiersprache ActionScript sich ja auch an diese Sprache anlehnt und sich der Quellcode so einfach durchgängiger lesen lässt. Für die Kommentare kann es von Vorteil sein, diese in Deutsch zu halten, falls viele deutschsprachige Entwickler mit mangelnden Englischkenntnissen im Team sind oder anschließend eine deutschsprachige Dokumentation gefordert ist. Internationale Unternehmen fordern aber auch hier meistens Englisch.
Es ist hilfreich, Eigenschaften einen beschreibenden Namen zu geben und Methoden mit einem Verb im Imperativ (Befehlsform) zu versehen, um die Bezeichner von Eigenschaften und Methoden leichter unterscheiden zu können:
function loadView () { }; // lade Ansicht
var loadedView:String; // geladene Ansicht
var viewLoaded:Boolean; // Ansicht geladen?
Bei Eigenschaften ist es außerdem empfehlenswert, bereits im Bezeichner zu kennzeichnen, welchen Typ an Information sie verwalten. Ob es sich dabei um ein Suffix (angehängte Zeichenkette) oder ein Präfix (vorangestellte Zeichenkette) handelt, ist Geschmackssache. Im Zweifelsfall können Sie ja die Suffixe von Macromedia übernehmen (siehe Tabelle):
// Ein paar mögliche Bezeichner für einen MovieClip
var name_mc:MovieClip; // Macromedias Variante
var mc_name:MovieClip;
var nameMc:MovieClip;
var mcName:MovieClip;
Tabelle 18.3
Macromedias Suffixe für Variablen
Objekttyp
|
Suffix
|
Array
|
_array
|
Button
|
_btn
|
Camera
|
_cam
|
Color
|
_color
|
ContextMenu
|
_cm
|
ContextMenuItem
|
_cmi
|
Date
|
_date
|
Error
|
_err
|
LoadVars
|
_lv
|
LocalConnection
|
_lc
|
Microphone
|
_mic
|
MovieClip
|
_mc
|
MovieClipLoader
|
_mcl
|
PrintJob
|
_pj
|
NetConnection
|
_nc
|
NetStream
|
_ns
|
SharedObject
|
_so
|
Sound
|
_sound
|
String
|
_str
|
TextField
|
_txt
|
TextFormat
|
_fmt
|
Video
|
_video
|
XML
|
_xml
|
XMLNode
|
_xmlnode
|
XMLSocket
|
_xmlsocket
|
18.3.2 Typisierung
Grundsätzlich zählt eine konsequente Typisierung zu den wichtigsten Regeln, um Fehler zu vermeiden. Doch ab und an scheint Typisierung nicht zu funktionieren, wie das folgende Beispiel zeigt.
Probleme mit der Typisierung bei der Verwendung von Rückruffunktionen.
Angenommen Sie haben eine DataLoader-Klasse, die das Laden von XML-Daten verwaltet, und nutzen in dieser Klasse eine Instanz der XML-Klasse zum Laden. Dann handelt es sich bei dieser XML-Instanz letztendlich um eine vom DataLoader aggregierte (also im Besitz befindliche) Instanz. Die XML-Instanz muss nun ihrem Besitzer, also dem DataLoader, eine Nachricht senden, sobald Daten empfangen werden. Doch anders als bei MovieClips gibt es hier keine automatisch erzeugte _parent-Eigenschaft mit Referenz auf den Besitzer.
class DataLoader {
function loadData() {
var my_xml;
my_xml = new XML();
my_xml.onLoad = function() {
// Teile das Ergebnis der übergeordneten Instanz mit
// instanzVonDataLoader.onLoadData();
// _parent geht nicht
// ...
};
}
function onLoadData() {
}
}
Eine Lösung dieses Problems wäre, wie im Folgenden auf die Typisierung zu verzichten und der XML-Instanz eine Referenz auf den DataLoader mitzuteilen. Das this innerhalb der Funktion mit dem Verweis auf den owner (engl. für Besitzer) muss verwendet werden, um auf den Gültigkeitsbereich der XML-Instanz zu verweisen. Ohne this findet Flash an dieser Stelle keinen owner! Der Verzicht auf die Typisierung öffnet fehlerhaftem Code Tür und Tor, weshalb davon abzuraten ist.
class DataLoader {
function loadData() {
var my_xml;
my_xml = new XML();
my_xml.owner = this;
my_xml.onLoad = function() {
// Teile das Ergebnis der übergeordneten Instanz mit
this.owner.onLoadData();
};
}
function onLoadData() {
}
}
owner
Ähnlich wenig empfehlenswert wie die vorhergehende Lösung ist der Versuch, die Typisierung nur für die eine Eigenschaft owner auszuhebeln:
class DataLoader {
function loadData() {
var my_xml:XML;
my_xml = new XML();
// Verhindert Typisierung durch Zugriff mit ["bezeichner"]
my_xml["owner"] = this;
my_xml.onLoad = function() {
// Teile das Ergebnis der übergeordneten Instanz mit
this.owner.onLoadData();
};
}
function onLoadData() {
}
}
Eine selbst erstellte Klasse mit der Eigenschaft owner ist die sauberste, aber leider auch aufwändigste Lösung. Diese Klasse beherrscht dank Vererbung alles, was auch die Klasse XML kann:
class DataXML extends XML {
var owner:Object;
}
class DataLoader {
function loadData() {
var my_xml:DataXML;
my_xml = new DataXML();
my_xml.owner = this;
my_xml.onLoad = function() {
// Teile das Ergebnis der übergeordneten Instanz mit
this.owner.onLoadData();
};
}
function onLoadData() {
}
}
Die letzte und aufgrund des geringen Aufwandes beliebteste Lösung ist eine lokale Variable namens owner. Lokale Variablen haben die Eigenheit, dass sie im gesamten Kontext einer Funktion inklusive der darin deklarierten Objekte und Methoden zur Verfügung stehen – egal wie tief geschachtelt die Objekte erstellt werden. Aus diesem Grund darf auch dieser Variablen kein this vorangestellt werden, da es sich dann um einen anderen Gültigkeitsbereich handeln würde.
Zwar ist der Programmcode dann etwas schwieriger zu lesen, da die lokale Variable nur schwer von einer Eigenschaft zu unterscheiden ist, aber wenigstens bleibt die Typsicherheit erhalten:
class DataLoader {
function loadData() {
var owner:DataLoader;
var my_xml:XML;
my_xml = new XML();
my_xml.onLoad = function() {
// Teile das Ergebnis der übergeordneten Instanz mit
owner.onLoadData();
};
}
function onLoadData() {
}
}
18.3.3 Codehinweise
Um eine Unterstützung des Flash-Editors bei der Entwicklung zu erhalten, gibt es die Codehinweise. Flash blendet dabei die verfügbaren Eigenschaften und Methoden eines Objektes ein, sofern der Typ bekannt ist. Dabei ist es für die Codehinweise egal, ob Sie eine richtige Typisierung vornehmen
var eigenschaft:Typ;
oder ob Sie den Typ in einem Kommentar ausschließlich zur Anzeige von Codehinweisen vorgeben (inklusive dem Semikolon):
// Typ eigenschaft;
oder ob Sie mit einer eindeutigen Zeichenfolge im Bezeichner arbeiten (siehe Tabelle »Suffixe«):
eigenschaft_suffix;
Sollten Sie mit den Codehinweisen nicht zufrieden sein, so können Sie zumindest die von Flash erkannten Zeichenfolgen anpassen. Diese finden Sie im Konfigurationsordner, meist C:\Dokumente und Einstellungen\[Benutzer]\Lokale Einstellungen\Anwendungsdaten\Macromedia\Flash MX 2004\[Sprache]\Configuration\, unter der Bezeichnung AsCodeHints.xml im Verzeichnis ActionsPanel (siehe »Entwicklungsumgebung anpassen« ab Seite 99). Flash unterscheidet hier zwischen Mustern (engl. Pattern) für Codehinweise, die automatisch vervollständigt werden, und Typangaben, anhand derer die zulässigen Eigenschaften und Methoden angeboten werden. Glücklicherweise dürfen Sie hier eigene Angaben vornehmen. Das folgende Beispiel erlaubt das Präfix mc_ für Movieclips und vervollständigt bei der Angabe von Application. die Anweisung mit einer der beiden angegebenen Varianten:
<codehints>
<codehint pattern="Application.start();\n}\n" />
<codehint pattern="Application.stop();\n}\n" />
<typeinfo pattern="mc_*" object="MovieClip" />
</codehints>
18.3.4 Kommentare und Dokumentation
Hier klicken, um das Bild zu Vergrößern
Abbildung 18.4
Automatisch generierte Dokumentation des Quellcodes (mit Jellyvision ActionDoc erzeugt)
Nicht nur zur Orientierung ist es erforderlich, den Programmcode zu kommentieren und zu dokumentieren. Für viele Auftraggeber gehört zum Ende eines Projektes eine Dokumentation mit zur erfolgreichen Übernahme. Da wäre es natürlich hilfreich, wenn die Dokumentation automatisch generiert werden könnte. Flash bietet jedoch keine Werkzeuge dafür. Das von Macromedia für die eigene Code-Dokumentation verwendete Werkzeug mit dem Namen ASDoc ist nicht für Normalsterbliche erhältlich. So bleibt nur die Suche nach einer Alternative …
JavaDoc
Der Standard für Kommentare und daraus generierte Dokumentation ist JavaDoc. JavaDoc funktioniert jedoch nicht gemeinsame mit ActionScript, da die Syntax von Java und ActionScript zu unterschiedlich ist. Doch immerhin halten sich alle bekannten Zusatzwerkzeuge für Flash an den von JavaDoc etablierten Standard für die Angabe der Kommentare – der ActionScript-Editor SE|PY erlaubt bereits die automatische Generierung von JavaDoc-ähnlichen Kommentaren (siehe »Werkzeuge«).
JavaDoc-Kommentarblöcke zur Beschreibung von Klassen, Eigenschafen und Methoden werden mit /** eingeleitet und mit */ beendet. Die dazwischen liegenden Zeilen beginnen mit einem *. Je nach verwendetem Werkzeug sind in den Zeilen weitere Angaben erlaubt, um beispielsweise Parameter oder den Autor anzugeben – diese werden meist mit einem @ eingeleitet. Aus diesen Angaben und dem eigentlichen Code erzeugen Werkzeuge wie die in der Tabelle angegebenen eine Dokumentation. Beispielsweise führt der folgende ActionScript-Code mit JavaDoc-Kommentaren zu der in der Abbildung 18.4 dargestellten Dokumentation, sobald ein Werkzeug wie ActionDoc zum Einsatz kommt:
/**
* Freundin
*
* @author Sascha Wolter
* @see <a href="http://www.saschawolter.de">Sascha Wolter</a>
* @version 1
*/
class Freundin {
public var kreativ:Boolean;
/**
* Freundin
*
* @param Void
*/
function Freundin(Void) {
kreativ = true;
}
/**
* tanze
*
* @param Void
* @return Void
*/
function tanze(Void):Void {
trace("yippi!");
}
}
|