Quelltext der Seite Wikipedia:Technik/Skin/JS/Datenelemente

{{../../../!header
|Text=JavaScript-Variablen im Wiki-Projekt}}
Diese Seite diskutiert die allgemeine Handhabung von Variablen und anderen Datenelementen im [[JavaScript]]-Code für Wiki-Projekte. Zu bestimmten MediaWiki-Variablen siehe: [[../Variablen|JS/Variablen]].

== Generierung ==
Eine Variable kann auf eine von drei Arten entstehen:
# Ein bisher unbenutzter Variablenname wird verwendet. ''([[#undefined|mehr]] dazu)''
# Eine Deklaration mit [[#var|{{Hilfe/tt|1=var}}]].
# Die Definition einer benannten <syntaxhighlight lang="javascript" inline>function</syntaxhighlight> generiert eine Variable, deren Wert ein spezielles Funktionsobjekt ist.
#* In den Browsern wird die so entstandene Variable unter dem Funktionsnamen meist so behandelt, als ob sie mit <code>var</code> deklariert worden wäre.
#* Die Argumente einer Funktion lassen ebenfalls innerhalb dieser Funktion Variablen entstehen.
Eine ohne <code>var</code> entstandene Variable lässt sich möglicherweise mit <syntaxhighlight lang="javascript" inline>delete</syntaxhighlight> löschen; mit <code>var</code> ist das nicht möglich.

Nicht als Variable betrachtet werden hier die Komponenten eines Objekts.

== Scopes ==
Der Scope ist der Gültigkeitsbereich, in dem eine Variable bekannt ist und ihr Wert gesetzt und verwendet werden kann.

=== Global scope ===
Zum „globalen Gültigkeitsbereich“ gehört:
# Jede Variable, die nicht innerhalb einer Funktion mit [[#var|{{Hilfe/tt|1=var}}]] deklariert wird oder Argument ist.
# Jede Variable, die nicht Komponente eines Objekts ist.
„Global“ meint: Alle Skripte, die bisher irgendwann in die HTML-Seite eingebunden wurden, nicht nur eine Seite mit einem einzelnen Benutzerskript.

=== Function scope ===
* Gültigkeit ausschließlich innerhalb einer Funktion haben solche Variablen, die innerhalb der Funktion mit [[#var|{{Hilfe/tt|1=var}}]] deklariert sind.
* Gibt es mit gleichem Namen eine globale Variable, wird die mit <code>var</code> deklarierte Funktionsvariable verwendet (Maskierung).
* War ansonsten zuvor eine globale Variable implizit oder explizit entstanden, wird diese verwendet und ggf. auch verändert.
* Ist die Variable innerhalb der Funktion nicht mit <code>var</code> deklariert, entsteht dadurch bei Ausführung der Funktion eine globale Variable.
Die Beschränkung der Gültigkeit auf die Funktion nennt man auch “closure”.
* Die Argumente der Funktion haben innerhalb dieser Funktion lokale Gültigkeit, als ob sie mit <code>var</code> vereinbart wären.

=== Clause scope ===
In der folgenden try-catch-clause definiert sich automatisch eine Variable, hier&nbsp;<code>e</code>:
<syntaxhighlight lang="javascript" style="border: none; margin-left: 2em; padding: 0.5em;">
   try {
      dubioscall();
   } catch (e) {
      window.alert("Fehler: " + e);
   }
</syntaxhighlight>
Die Variable <code>e</code> ist lokal in der catch clause. Innerhalb dieses Blocks kann sie ausgewertet werden; anschließend existiert sie nicht mehr. Andere Variablen gleichen Namens würden vorübergehend verdeckt werden, aber man sollte unnötige Namensdopplungen vermeiden.

=== Block scope ===
Vorweg: Anders als in anderen Programmiersprachen gibt es in JavaScript keinen Block scope.

Ein Beispiel in [[C (Programmiersprache)|C]]:
<syntaxhighlight lang="c">
   int XY(int elems[])
   {
      int k  =  0;
      // ...
      {
         size_t n  =  sizeof(elems) / sizeof(int);
         // ...
         for (size_t i = 0;  i < n;  i++) {
            k  =  10 * k  +  elems[i];
         }   // for i
         // ...
      }
      // ...
      return (k);
   }
</syntaxhighlight><!-- K&R: return () -->
Hier ist die Variable <code>n</code> nur in den umschließenden Klammern bekannt, der Schleifenindex <code>i</code> nur innerhalb der Schleife; außerhalb sind <code>n</code> und <code>i</code> undeklariert und würden zu einem Syntaxfehler führen.

In Anlehnung daran schreiben manche Programmierer in JavaScript, wenn angedeutet werden soll, dass die Verwendung von <code>i</code> nur innerhalb der Schleife beabsichtigt ist:
<syntaxhighlight lang="javascript">
   function XY(elems) {
      var k  =  0;
      var n  =  elems.length;
      // ...
      for (var i = 0;  i < n;  i++) {
         k  =  10 * k  +  elems[i];
      }   // for i
      // ...
      return k;
   }
</syntaxhighlight>
Hier wirkt sich die Deklaration <syntaxhighlight lang="javascript" style="padding:0.5em" inline>var i</syntaxhighlight> aber über die gesamte Funktion aus.

Damit auch Monate später und andere Bearbeiter auf Anhieb die Codierung erfassen, sollten deshalb alle <code>var</code> am Beginn des scope gesammelt werden; dies entspricht dann auch der tatsächlichen Wirkung.

Zwar gibt es keinen Block scope, jedoch die Möglichkeit, einen Block in runde Klammern zu setzen, damit eine Pseudo-Funktion zu bilden und diese dann „aufzurufen“.<ref>siehe [[mw:Manual:Coding conventions/JavaScript #Closures]]</ref> Das entspräche einer [[#Anonyme Funktion|anonymen Funktion]]:
<syntaxhighlight lang="javascript">
   ( function ( w ) {
           "use strict";
           if ( ! w.what ) {
              w.what  =  {};
           }
   } ( window ) );
</syntaxhighlight>
Der Informationsfluss wird kontrolliert; das Innere das Blocks kann auf die Umgebung zugreifen, aber das Innere ist von außen nur über die aufgezählten Parameter zugreifbar.

=== Stack scope ===
Immer dann, wenn durch [[Multithreading]] mehrere Prozesse entstehen, kann es zu mehrfachem Global scope kommen&nbsp;– eine Art Paralleluniversum.
In einem Browser kann das geschehen, wenn
* <code>window.setTimeout()</code> oder <code>window.setInterval()</code> benutzt wird.
* Skripte asynchron geladen werden, wie das seit Anfang 2011 durch [[Google Chrome]] und seit Mitte 2011 durch [[Mozilla Firefox|Firefox]] praktiziert wird.
In dem Moment, in dem ein Kindprozess ausgebrütet wird, bekommt es eine vollständige Kopie des Global scope mit auf den Weg. Der Elternprozess behält seinen Global scope. Ändert der Kindprozess den Wert einer Variablen oder fügt eine hinzu, bekommt der Elternprozess davon nichts mit; genauso kann der Elternprozess unabhängig agieren, ohne dass der Kindprozess etwas bemerkt. Später eintreffende Ereignisse werden an den verursachenden Prozess dirigiert. – Oder es wurde beim Wiederaufnehmen das momentane globale Objekt durch das eingefrorene globale Objekt überschrieben. Damit würden zwischenzeitlich eingetroffene Änderungen überschrieben, die durch Ereignisse wie eintreffende Ajax-Abfragen oder asynchrones Laden bewirkt worden waren.

In den Standards auch der [[Ecma International|ECMA]] zu JavaScript ist dazu nichts festgelegt.<ref>ECMA-262/5: 15.1 “The Global Object”; 10.3, “execution context”</ref> Die Programmierer von Browsern sind frei, wie sie mit der Situation umgehen wollen. Zurzeit (2012) sind auch die Debugger wie [[Firebug]] bei der Darstellung der Variablen nicht in der Lage, die unterschiedlichen Global scopes zu unterscheiden; man sieht anscheinend immer den ursprünglichen Elternprozess.

Der einzig erwiesenermaßen sichere Weg ist es, das [[#window|{{Hilfe/tt|1=window}}]]-Objekt und seine weiteren Komponenten zu verwenden. Hiervon gibt es genau eines, und bei der Ansprache der jeweiligen Komponente eines Objekts wird auf dessen übergeordnetes Objekt zugegriffen.

Vielleicht gibt es ja irgendwann eine Lösung in allen Browserversionen, die wieder nur einen einzigen Global scope pro Fenster kennt. Mit Umsetzung des <code>"use&nbsp;strict"</code> aus ECMA 3/5 in den Browsern sollte es mittelfristig dazu kommen, dass jedes globale Objekt immer auch auf genau ein und dasselbe <code>window</code>-Objekt abgebildet ist. Auch wenn alle Browser-Familien dies berücksichtigen sollten, wird es noch auf lange Zeit abweichende Browser-Versionen bei den Benutzern geben. Die Programmierung innerhalb der Wiki-Projekte muss deshalb der Möglichkeit Rechnung tragen.

=== {{Anker|window}} window scope ===
JavaScript in einem Wiki-Projekt ist dafür vorgesehen, dass es in einem Fenster/Tab eines Browsers abläuft. In einem Browser-Fenster ist immer das globale Objekt <code>window</code> definiert. Das muss in JavaScript nicht so sein; man kann ein Skript auch lokal auf dem Rechner ohne Browser starten (etwa mit [[JScript]]). Deshalb machen die Standards zu ECMA/JavaScript auch keine Vorgaben, wie das <code>window</code>-Objekt und globale Variablen zusammenhängen. Definiert ist lediglich für JavaScript, wie Browser-Aktivitäten und das HTML-Dokument mit dem <code>window</code>-Objekt verbunden sind.

Übrigens ist nicht nur in einem Browser-Fenster, sondern innerhalb dessen auch in jedem <code>iframe</code> ein eigenständiges globales Objekt erforderlich.

Firefox stellt alle globalen Variablen automatisch auch als Komponenten von <code>window</code> dar; der Internet Explorer von Microsoft macht dies nicht. Ob sie aber echte (und “configurable”) Komponenten von <code>window</code> sind, ist auch in den Firefox-Versionen nicht ganz klar. Deshalb ist es dringend ratsam, beabsichtigte globale Variablen explizit unmittelbar oder mittelbar zu Komponenten von <code>window</code> zu machen.

Im Zusammenhang mit [[Greasemonkey]] und Add-Ons kann es dazu kommen, dass es außerhalb des Browser-Fensters, in dem das HTML-Dokument wirksam ist, ein oder mehrere weitere globale Objekte gibt, die erweiterte Zugriffsrechte haben und auf das <code>window</code>-Objekt des DOM/HTML-Dokuments zugreifen. Sie heißen möglicherweise ebenfalls <code>window</code> und lassen sich an der Zugriffsmöglichkeit auf das DOM-<code>window</code> erkennen.
<!-- this   Komplexe Angelegenheit; scope-abhängig und oft nicht auf Anhieb sichtbar. -->

=== {{Anker|wiki scope}} Kapselung für Wiki-Projekte ===
Bei neueren Programmierungen in einem Wiki-Projekt soll der Code immer als ''[[#Function scope|function scope]]'' wie folgt gekapselt werden:
<syntaxhighlight lang="javascript" style="margin-left: 2em; margin-bottom: 1em;">
( function ( mw, $ ) {
   "use strict";
   // ...
   // ...
}( window.mediaWiki, window.jQuery ) );
</syntaxhighlight>
Wirkung:
* Alle inneren Deklarationen von Variablen und Funktionen haben keine Wirkung nach außen und stören dort nicht.
* Parallele Skripte, etwa durch [[Greasemonkey]] oder Benutzerskripte, beeinflussen das Innere der Kapsel nicht.
* Nur wenn durch andere Skripte die Namen <code>mediaWiki</code> oder <code>jQuery</code> überschrieben würden, käme es zum Konflikt.
* Die Variablen <code>mw</code> und <code>$</code> bezeichnen innerhalb der Kapsel dieselben Objekte wie die jeweiligen Langformen. Nur diese Namen sollten benutzt werden, um sie bei der Suche nach Zeichenketten leicht auffinden zu können. Außerdem werden dadurch die Programmzeilen kürzer.
* Andere Variablen mit den zufällig gleichen, wenig spezifischen zwei Buchstaben <code>mw</code> oder auch <code>$</code> werden durch das Innere der Kapsel nicht berührt.
* Die Objekte <code>mediaWiki</code> wie auch <code>jQuery</code> sind eine Eigenschaft des Objektes <code>window</code> und damit eindeutig in der aktuellen Browser-Seite, auch wenn sich bei asynchroner Bearbeitung mehrere Instanzen ergeben.
Anmerkung: Von mediawiki.org wird gelegentlich empfohlen, als dritten Parameter <code>undefined</code> zu deklarieren. Dies ist jedoch unzulässig; <code>undefined</code> ist ein reserviertes Schlüsselwort und darf nicht als Funktionsargument verwendet werden.

== {{Anker|var}} var zur Deklaration ==
Die Zuweisung mit <code>var</code> ist in JavaScript die einzige durchgehend echte Deklaration; im Unterschied zu anderen Programmiersprachen, die wesentlich mehr deklarative Anweisungen kennen. Alle anderen Syntaxelemente in JavaScript sind (zumindest bei vielen Browser-Versionen) tatsächlich ausführbare Anweisungen. Nur die <code>function</code>-Deklaration (jedoch im Unterschied zur <code>function</code>-Zuweisung) soll zukünftig immer analog gehandhabt werden.

=== {{Anker|var.scope}} Gültigkeitsbereich ===
Egal, an welcher Stelle im Scope das <code>var</code>-Statement steht&nbsp;– Deklarationen wirken sich immer auf den vollen Gültigkeitsbereich aus ([[#Function scope|function]] oder [[#Global scope|global]]).

Das gilt auch, wenn das <code>var</code>-Statement in eine if-Konstruktion eingeschlossen wird:
<syntaxhighlight lang="javascript" style="border: none; margin-left: 2em; padding: 0.5em;">
 if (lucky) {
    var x = 1;
 }
</syntaxhighlight>
Im globalen Gültigkeitsbereich wäre <code>x</code> überall definiert, würde eine vorherige Definition auch maskieren. Nur im Fall <code>lucky</code> würde zusätzlich der Wert <code>1</code> zugewiesen.

Um den Überblick über die in einer Einheit (global oder function) definierten <code>var</code>-Statements zu behalten, empfiehlt es sich dringend, sie ganz am Anfang anzuordnen. Wenn es viele sind, sollten sie auch inhaltlich oder alphabetisch sortiert werden. Wenn ihr Name nicht für sich selbst spricht, ist es ratsam, auch gleich noch einen Kommentar mit Erklärung anzuhängen. Es ist auch der geeignete Ort für eine Initialisierung.

=== Formatierung ===
MW praktiziert die Anordnung in einem einzigen Statement, durch Kommata getrennt ([[mw:Manual:Coding conventions/JavaScript|Coding conventions]]).

Dem kann man folgen oder auch nicht. Lässt man jede Deklaration als gesondertes Statement einzeln in einer Zeile stehen,<ref name="var1" /> kann man alle Zeilen filtern, die den Variablennamen enthalten oder mit <code>var</code> beginnen, und so einen Gesamtüberblick bekommen. Auch die gleichzeitige Initialisierung wird damit übersichtlicher.

=== Mehrfache Zuweisung ===
JavaScript erlaubt mehrere Zuweisungen in einem Statement. Immer wieder kommt es dabei zu Programmierfehlern:
<syntaxhighlight lang="javascript" style="border: none; margin-left: 2em; padding: 0.5em;">
  var x = y = 100;
</syntaxhighlight>
Sowohl <code>x</code> wie auch <code>y</code> erhalten den Wert 100. Aber nur <code>x</code> ist mit <code>var</code> deklariert und in einer Funktion eine lokale Variable. Dagegen ist <code>y</code> jetzt eine globale Variable, was in der Funktion wohl nicht beabsichtigt war und dem menschlichen Leser kaum auffällt.

=== <code>const</code> und <code>let</code>  ===
Ursprünglich kein standardisiertes JavaScript waren die beiden Deklarationen
* <code>const</code> für konstante Werte, die nicht mehr irrtümlich geändert werden können (Mozilla JS&nbsp;1.5<ref>[https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Statements/const MDN]</ref>)
* <code>let</code> für Zuweisungen mit Block scope (Mozilla JS&nbsp;1.7<ref>[https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Statements/let MDN]</ref>)
Zumindest bis zum IE10 war dies ein Syntaxfehler. Im Entwurf zu ECMA-6 vom April 2012 werden sie hingegen als neue Syntaxelemente gefordert. Gleichwohl wird es einige Jahre dauern, bis alle Benutzer der Wikis entsprechende Skripte ohne Absturz nutzen können. Die Implementierungsdetails beim Firefox unterscheiden sich von ECMA.

Für die meisten Skripte im Wiki werden diese keinen Vorteil bieten. <code>var</code> kann problemlos weiter genutzt werden. Es erwartet eine Deklaration zu Beginn der Funktionseinheit und dort sind alle auftretenden Symbole innerhalb der Funktion übersichtlich zusammengestellt. Unabhängige Nutzung desselben Namens in Blöcken kann auch verwirren. Versehentliche Umdefinition eines als <code>const</code> beabsichtigten Wertes ist bei überschaubaren Skripten kein typischer Fehler.

== {{Anker|globalNS}} Globale Variablen und die anderen Benutzer ==
Vorweg: Wenn du nur für dich alleine programmierst&nbsp;– mach, was du willst. Insbesondere, wenn du keine Skripte anderer Benutzer einbindest.

{| {{Bausteindesign8}}
| Wenn du dein Skript aber anderen Benutzern zur Verfügung stellst, gar ein projekt- bis weltweites Gadget auf der Seite [[WP:Helferlein|Helferlein]] anbieten möchtest&nbsp;– dann solltest du unter den Bedingungen von 2012 bei Neuprogrammierungen oder grundlegenden Überarbeitungen keine globale Variable mehr in die Welt setzen, möglichst auch keine mehr erwarten.
|}

In früheren Zeiten hatten die „Monobooks“ locker 250 globale Variablen kreiert; hinzu kamen einige Dutzend Funktionsdefinitionen. Dazu möglicherweise noch ein Dutzend Importe an Skripten anderer Benutzer, die ebenfalls großzügig globale Variablen verstreuten; mit den ''[[../Obsolet#wikibits|wikibits]]'' sammelte sich ein freundliches Hundert an Funktionen.&nbsp;–&nbsp;– Nach einigen Jahren war es vielleicht noch dem Skriptautor persönlich möglich, sich durch diesen Dschungel durchzufinden&nbsp;– aber Namenskonflikte<ref>„[[Special:PermanentLink/99386629?title=MediaWiki:Gadget-PB2.js|{{Hilfe/tt|1=msg}}]]“ oder das Array <code>ta[]</code> in wikibits</ref> sind unvermeidlich, gerade wenn im gleichen Themengebiet ähnliche Aktivitäten entfaltet werden. Mehrere functions und Variablen unterschiedlicher Herkunft können leicht unterschiedliche Bedeutungen haben und zu unentwirrbaren Folgefehlern führen. Sicherheitstechnisch ist das überhaupt nicht mehr zu beherrschen, wenn irgendwo ein schwarzes Schaf eingeschmuggelt wird. Interaktionsprobleme mit neuen Browser-Versionen und einfach nur seltsames, nicht reproduzierbares Fehlverhalten bleibt unaufgeklärt.

Zwei Wege mit ihren Vor- und Nachteilen führen aus dem perfekten Chaos.

=== Anonyme Funktion ===
In vielen Fällen wird ohnehin eine Funktion als Übergabewert erwartet. Sie kann [[Anonyme Funktion|namenlos]] als Parameter geschaffen werden:
<syntaxhighlight lang="javascript" style="border: none; margin-left: 2em;">
  jQuery(document).ready(function () {
     var n  =  document.links.length;
     if (window.xyz === ....
     // ....
                                     }   // function ()
  );   // jQuery(document).ready
</syntaxhighlight>
Nach dem Laden des Dokuments soll die Funktion ausgeführt werden. Genauso nach [[../ResourceLoader#.loader.using()|Bereitstellung eines Moduls]]:
<syntaxhighlight lang="javascript" style="border: none; margin-left: 2em;">
  mw.loader.using("mediawiki.util",
                  function () {
                     mw.loader.load(mw.config.get("wgServer")
                                    + mw.util.wikiScript()
                                    + "?title="
                                    + mw.util.wikiUrlencode(access)
                                    + "&action=raw&ctype=text/javascript",
                                    "text/javascript");
                  });
</syntaxhighlight>
{{Pro}} Die Funktion trägt keinen Namen, kann also mit keiner anderen gleichen Namens kollidieren.<br />
{{Pro}} “Pollution of global namespace” („Verschmutzung des globalen Namensraums“) unterbleibt somit.<br />
{{Pro}} Anwender haben keinerlei Zugriff und können die inneren Abläufe nicht manipulieren.<br />
{{Kontra}} Die Funktion kann nicht wiederverwendet werden, an keiner anderen Stelle aufgerufen werden.

Zusammengefasst eignet sich das Konzept der anonymen Funktion besonders für folgende Fälle:
* Der Code wird nur speziell in einer bestimmten Situation gebraucht und kann nie wieder benötigt werden; wird ggf. nur ein einziges Mal ausgeführt.
* Der Code ist relativ kurz, überschaubar und kann einmalig ausgetestet bereitgestellt werden.
* Man will bestimmte Funktionalitäten nicht dauerhaft anbieten und unterstützen müssen und will lediglich intern benötigte Eigenschaften vor den Benutzern verstecken, damit man jederzeit die inneren Abläufe verändern kann.
''Anmerkung:'' Es ist möglich, anonyme Funktionen zu Debugging-Zwecken während der Entwicklung mit „Bezeichnern“ zu versehen, unter denen sie im Aufrufstapel leicht zu identifizieren sind. Diese „benannten Funktionsausdrücke“ sind aber nicht kompatibel mit allen Browsern und Versionen der Wikipedia-Benutzer und sollten deshalb nur vorübergehend und für eigene Zwecke benutzt werden; sie lassen sich ja mit <syntaxhighlight lang="javascript" inline>/* ... */</syntaxhighlight> auskommentieren.<ref>[http://kangax.github.com/nfe/ ''Named function expressions demystified''] (englisch)</ref>

=== Anwendungsobjekt ===
Im [[../mw|{{Hilfe/tt|1=mw}}-Objekt]] wurde im Herbst 2011 eine öffentlich zugängliche Komponente [[../mw#.libs|{{Hilfe/tt|1=mw.libs}}]] eingeführt. Sie solle dazu benutzt werden, um Erweiterungen anzudocken&nbsp;– wie genau man sich dies vorstellt, wurde nicht verlautbart.

Man kann nun ein „Anwendungsobjekt“ für seine Problemlösung definieren. Alle Funktionen und Variablen werden zu Komponenten in diesem Anwendungsobjekt und sind dem Global scope entzogen.

Dockt man sein Anwendungsobjekt nun an <code>mw.libs</code> an, sollte die Ausführung auch bei [[#Stack scope|mehrfachen Threads]] sicher sein, da das mw-Objekt Komponente von [[#window|{{Hilfe/tt|1=window}}]] ist. Zwar besteht hier immer noch die Gefahr von Namenskonflikten mit anderen Anwendungsobjekten gleichen Namens, aber dies ist auf einen Bezeichner pro Anwendung reduziert.

Die Definition erfolgt wie folgt:
<syntaxhighlight lang="javascript" style="border: none; margin-left: 2em; padding: 0;">
 mw.libs.myApplication  =  { };
</syntaxhighlight>
Man sollte direkt unter <code>mw.libs</code> nur Anwendungen einfügen, die seitens der prinzipiellen Funktionalität und auch durch ihre Namensgebung internationalisierbar sind (deren Name somit auf dem Englischen basiert).

Eher deutschsprachige Anwendungen sollten lieber die Komponente <code>dewiki</code> benutzen:<ref name="mw.libs.dewiki" /><ref name="mw.libs.cryptic" />
<syntaxhighlight lang="javascript" style="border: none; margin-left: 2em;">
 if (! mw.libs.dewiki) {
    mw.libs.dewiki  =  { };
 }
 mw.libs.dewiki.MeineAnwendung  =  { };
</syntaxhighlight>
Alle weiteren Einzelfunktionen und Daten werden nun als Komponenten des Anwendungsobjekts strukturiert.


{{Pro}} “Pollution of global namespace” („Verschmutzung des globalen Namensraums“) unterbleibt.<br />
{{Pro}} Es lässt sich sofort nachvollziehen, welchen Paketen welche Funktion entstammt. Konfigurationsdaten lassen sich ebenfalls leicht und zweifelsfrei der Anwendung zuordnen.<br />
{{Pro}} Eine Einzelfunktion kann mit keiner anderen gleichen Namens kollidieren.<br />
{{Pro}} Die Funktionen können wiederverwendet, also beliebig aufgerufen werden. Insbesondere eignet sich dies dazu, eine [[Programmierschnittstelle|API]] anzubieten.<br />
{{Pro}} Die Funktionen sind im Debugger leicht zu überwachen.<br />
{{Pro}} Komplexe Strukturen können aufgebaut werden.<br />
{{Pro}} Auch innerhalb eines Anwendungsobjekts sind anonyme und damit unzugängliche Strukturen definierbar.<ref>Siehe beispielsweise die Programmierung von <code>mw.loader</code> oder das <code>mw</code>-Objekt selbst.</ref><br />
{{Kontra}} Anwender haben Zugriff auf öffentliche Komponenten, könnten die inneren Abläufe manipulieren oder unerwünscht aufrufen.<br />
{{Kontra}} Es könnte ein Namenskonflikt mit einem anderen Anwendungsobjekt ähnlicher Funktion auftreten.

Zusammengefasst eignet sich das Konzept des Anwendungsobjekts besonders für folgende Fälle:
* Der Code soll mehrfach ausgeführt werden können und auch von Benutzern aufgerufen werden.
* Benutzer sollen Konfigurationsdaten vorgeben können.
* Der Code ist komplex und umfangreich; es ist mit ständiger Weiterentwicklung zu rechnen.


{{Anker|appObj.config}}
Eine Benutzerkonfiguration verwendet klassischerweise eine Komponente <code>.options</code>, <code>.opt</code> oder <code>.config</code>&nbsp;– am Beginn der Anwendungsprogrammierung muss mit der Existenz eines zuvor definierten leeren Anwendungsobjekts mit Konfigurationsdaten gerechnet werden:
<syntaxhighlight lang="javascript">
   if (! mw.libs.myApplication) {
      mw.libs.myApplication  =  { opt: { }
                                };
   }
   if (! mw.libs.myApplication.opt) {
      mw.libs.myApplication.opt  =  { };
   }
   if (typeof mw.libs.myApplication.opt.XYZ !== "string") {
      mw.libs.myApplication.opt.XYZ  =  "default";
   }
   if (typeof mw.libs.myApplication.opt.URL !== "string") {
      mw.libs.myApplication.opt.URL  =  "http://..........";
   }
</syntaxhighlight>
Wenn keine Validitätsprüfung erfolgen soll, geht dies eleganter mit
<syntaxhighlight lang="javascript">
   var options  =  { XYZ: "default",
                     URL: "http://.........."
                   };
   if (mw.libs.myApplication.opt) {
      options  =  jQuery.extend(options, mw.libs.myApplication.opt);
   }
</syntaxhighlight>
Dabei werden die Benutzerdaten <code>opt</code> nicht verändert; die interne Objekt-Komponente <code>options</code> wird mit den Default-Werten vorbelegt. Anschließend enthält <code>options</code> die gewünschten Einstellungen, je nach den Angaben in <code>opt</code> auch gemischt.

Auf Seiten eines Anwenders erfolgt auf Wunsch die analoge Definition von <code>mw.libs.myApplication.opt</code> mit entsprechenden Daten.

Schließlich sollte man in einem komplexen Objekt immer Versionshinweise unterbringen; entweder numerisch (als Dezimalzahl) oder als Zeichenkette; etwa mit Datum und Kurzkommentar:
<syntaxhighlight lang="javascript" style="border: none; margin-left: 2em;">
 mw.libs.dewiki.MeineAnwendung.version  =  "2012-02-25 1.4 debug P.C.";
</syntaxhighlight>

=== {{Anker|config.opt|user.config}} Benutzerdefinierte Konfigurationsdaten ===
Sollen Benutzer die Möglichkeit bekommen, das Verhalten von Skripten durch Vorgabe von Daten zu steuern, muss zunächst einmal sichergestellt sein, dass das Benutzerskript wie etwa <code>common.js</code> bereits ausgeführt worden ist. Das ist unter den modernen Bedingungen des asynchronen Ladens nicht mehr selbstverständlich.
* Wird die Anwendung erst mittels <code>mw.loader.load()</code> durch den Benutzer geladen, dann ist diese Vorbedingung automatisch erfüllt.
* Bei [[../ResourceLoader#Gadgets|Gadgets]] oder in [[../ResourceLoader#site|projektweiten Standardressourcen]] wie [[MediaWiki:Common.js]] ist das nicht zwingend der Fall.
Das abgeschlossene Laden der Standard-Benutzerskripte wird durch das Modul [[../ResourceLoader#user|{{Hilfe/tt|1=user}}]] signalisiert:
<syntaxhighlight lang="javascript" style="border: none; margin-left: 2em;">
 // Allgemeine Initialisierung der Anwendung
 // ...
 // kann bereits beim Laden erfolgen.
 mw.loader.using( "user", dieseAnwendung.run );
</syntaxhighlight>
Die Funktion <code>dieseAnwendung.run()</code> kann dann die Benutzerkonfiguration auswerten und unter ihrer Berücksichtigung die eigentlichen Aktivitäten entfalten.

==== Konfigurationsdaten im Anwendungsobjekt ====
Beim [[#Anwendungsobjekt|Anwendungsobjekt]] bietet sich eine Komponente [[#config.opt|{{Hilfe/tt|1=.options}}]] (auch <code>.opt</code> oder <code>.config</code>) an.

Benutzerseitig wird ein leeres Anwendungsobjekt vorgegeben und mit den gewünschten Einstellungen gefüllt; falls das Anwendungsobjekt schon existieren sollte, wird es nicht überschrieben.
<syntaxhighlight lang="javascript" style="border: none; margin-left: 2em;">
 if (! mw.libs.dieseAnwendung) {
    mw.libs.dieseAnwendung  =  { opt: { }
                               };
 }
 mw.libs.dieseAnwendung.opt.meinSonderwunsch  =  42;
</syntaxhighlight>
Die Anwendung selbst prüft beim Laden, ob zuvor ein Anwendungsobjekt definiert war, und wertet bei der eigentlichen Ausführung mögliche Konfigurationsdaten aus.

==== Benutzeroptionen in den allgemeinen Benutzereinstellungen ablegen ====
Ein für die Anwender komfortabler Weg ist die Speicherung in den [[Hilfe:Einstellungen|Benutzereinstellungen]]. Das [[Wikipedia:Technik/Skin/Benutzerskripte/Hinweise|Benutzerskript]] [[Benutzer:PerfektesChaos/js/preferencesGadgetOptions|preferencesGadgetOptions]] vereinfacht die Handhabung durch Programmierer und bietet den Anwendern ein interaktives Formular an.

==== Globale Benutzerkonfiguration ====
Gibt es kein Anwendungsobjekt, dann können Benutzerwünsche den [[../Variablen#mw.user|Optionen]] hinzugefügt werden.
Damit stehen sie nicht im globalen Namensraum und es ist auch sofort nachzuvollziehen, dass es sich um eine individuelle Einstellung handelt.

Das Modul <code>mediawiki.user</code> ist aber möglicherweise nicht sofort verfügbar, die benutzerseitige Zuweisung lautet deshalb etwas umständlich:
<syntaxhighlight lang="javascript" style="border: none; margin-left: 2em; padding: 0;">
 mw.loader.using( "mediawiki.user",
                  function () {
                     mw.user.options.set("meinSonderwunsch", 42);
                  } );
</syntaxhighlight>
Auf Seiten der Anwendung müsste die [[#config.opt|oben]] gegebene Bedingung erweitert werden:
<syntaxhighlight lang="javascript" style="border: none; margin-left: 2em; padding: 0;">
 mw.loader.using( [ "user", "mediawiki.user", "user.options" ],
                  Anwendung.run );
</syntaxhighlight>
In der Funktion <code>Anwendung.run()</code> kann mit
<syntaxhighlight lang="javascript" style="border: none; margin-left: 2em; padding: 0;">
 var udo  =  mw.user.options.get("meinSonderwunsch", false);
</syntaxhighlight>
der aktuelle Wert abgefragt werden.

=== {{Anker|config.set}} Globale Konfigurationseinstellungen ===
Eine elegante Möglichkeit, Konfigurationsdaten der Anwendung außerhalb der globalen Variablen unterzubringen, wenn kein [[#Anwendungsobjekt|Anwendungsobjekt]] vorhanden ist, wäre die [[../mw#.messages|Erweiterung der Systemnachrichten]]. Das gilt insbesondere für sprachabhängige Textelemente, wenn eines Tages ein international nutzbares Gadget auch von translatewiki unterstützt werden soll.
<syntaxhighlight lang="javascript" style="border: none; margin-left: 2em;">
 switch ( mw.config.get( "wgUserLanguage" ) ) {
    case "de":
    case "de-at":
    case "de-ch":
    case "de-formal":
       mw.messages.set( {
             "myTextBBshort": "Textbrösel",
             "myTextBBlong":  "lange Geschichte"
                        } );
       break;
    case "en":
    default:
       mw.messages.set( {
             "myTextBBshort": "text snippet",
             "myTextBBlong":  "longer story"
                        } );
       break;
 };   // switch wgUserLanguage
</syntaxhighlight>
Später ist dies wie jede (für JavaScript registrierte) Systemnachricht zu nutzen über:
<syntaxhighlight lang="javascript" style="border: none; margin-left: 2em; padding: 0;">
 var s  =  mw.messages.get( "myTextBBshort" );
</syntaxhighlight>

=== Good practice ===

Beabsichtigte globale Variablen und Funktionen sollten in der immer komplexeren Welt der Wiki-Skripte nur noch mit Bezugnahme auf ein Objekt verwendet werden. Damit wird zum einen die sichere Wirkung gewährleistet, zum anderen wird die beabsichtigte Funktion auf Anhieb und zweifelsfrei verstanden und es kann systematisch analysiert werden, etwa durch Suche nach Zeichenketten.

Geeignete Objekte sind namentlich:
* <code>window</code>
** <code>document</code>
* [[../mw#Name|{{Hilfe/tt|1=mw}}]]
* [[../jQuery|{{Hilfe/tt|1=jQuery}}]] bzw. <code>$</code>
* [[#Anwendungsobjekt|''Anwendungsobjekt'']] – sofern nicht ohnehin schon Komponente unter <code>mw.libs</code>
* <code>dewiki</code><ref name="mw.libs.dewiki" />
Damit lässt sich umgekehrt schließen: Ist kein Objekt-Bezeichner vorangestellt, dann handelt es sich um eine lokale Variable einer Funktion, die auch mit <code>var</code> deklariert worden sein sollte.

Es ist zu erwarten, dass eines Tages die Benutzerskripte gekapselt werden.<ref>{{Phab|Bugzilla=63728}}</ref> Das bedeutet, mit <code>var</code> deklarierte Variablen stehen dann nur noch innerhalb der Standard-Benutzerskripte zur Verfügung und haben keine Auswirkung mehr auf andere Skripte. Die Kommunikation sollte über geeignete Komponenten von [[../mw/libs|{{Hilfe/tt|1=mw.libs}}]] geleitet werden, um nicht das globale Objekt <code>window</code> genauso unstrukturiert zu fluten wie zuvor.

== {{Anker|undefined}} Undeklarierte Variablen ==
In jeder professionellen Programmierpraxis gelten undeklarierte Variablen als Fehler. JavaScript lässt das zwar zu&nbsp;– bedingt durch die Vorgeschichte Mitte der 1990er, als es um ein Dutzend Zeilen ging, die in eine HTML-Seite eingebettet wurden. Gleichwohl sollten alle Variablen explizit deklariert sein, im aktuellen Skript oder in einem zuvor geladenen (MediaWiki). In der komplexen Situation einer mit allerlei Gadgets verfeinerten Wiki-Seite sind Programmierfehler durch vertippte Variablennamen sonst nicht aufzuspüren, auch nicht mit Entwicklerwerkzeugen.

=== Initialisierung ===
Unabhängig von der Deklaration mit <code>var</code> steht die Frage der korrekten Initialisierung; wenn es einen an dieser Stelle sinnvollen Startwert gibt, dann sollte dieser zu Beginn und im <code>var</code> explizit gesetzt werden. (Eine <code>for</code>-Schleife wird im Zusammenhang mit Zahlenwerten belegt.)

=== {{Anker|declared}} Undeklariert und <code>undefined</code> ===
Alle Symbole gelten als „deklariert“, die
* mit <syntaxhighlight lang="javascript" inline>var</syntaxhighlight> in der Funktion oder global vereinbart wurden,
* Argument einer übergeordneten Funktion waren,
* durch [[#Clause scope|{{Hilfe/tt|1=catch}}]] gesetzt wurden,
* Eigenschaft eines Objekts sind (und damit jedes Element eines Array).
Daraus ergibt sich:
* {{Anker|isUndefined}} Wenn sichergestellt ist, dass eine Variable (oder Eigenschaft eines Objekts) deklariert ist, kann mit <syntaxhighlight lang="javascript" style="white-space:nowrap;" inline>x !== undefined</syntaxhighlight> der Status geprüft werden, also ob ein Wert beim Funktionsaufruf oder sonst zugewiesen wurde (Initialisierung?).
* {{Anker|undeclared}} Wenn nicht sichergestellt ist, ob die Variable bereits grundsätzlich existiert, ist zur Vermeidung von Laufzeitfehlern mit <syntaxhighlight lang="javascript" style="white-space:nowrap;" inline>typeof x</syntaxhighlight> abzuprüfen. Der Operator bzw. die Funktion <syntaxhighlight lang="javascript" inline>typeof</syntaxhighlight> ist die einzige, mit der ein undeklariertes Symbol in Verbindung gebracht werden darf. Das ist nicht ganz so schnell wie der Vergleich mit <syntaxhighlight lang="javascript" inline>undefined</syntaxhighlight>. Es eignet sich aber besonders, um herauszufinden, ob in anderen Skripten eine entsprechende Variable vorgegeben wurde. Außerdem lässt sich gleich prüfen, ob auch der erwartete Datentyp vorliegt. Spricht man jedoch globale Variablen als Eigenschaften des [[#window|<code>window</code>]]-Objekts an, lassen sie sich direkt mit <syntaxhighlight lang="javascript" inline>undefined</syntaxhighlight> vergleichen.

== this ==

Mit <syntaxhighlight lang="javascript" inline>this</syntaxhighlight> kann der aktuelle Kontext festgestellt werden.


''Außerhalb von Funktionen'' (im [[#Global scope|global scope]]) verweist <code>this</code> auf das “global object”. In einem Web-Browser sollte <code>window</code> das “global object” sein, im Regelfall ist also <code>this===window</code> (siehe aber [[#Stack scope|stack scope]]). Deshalb sollte in Wiki-Projekten hier explizit <code>window</code> benutzt werden.

Der mit <code>"use strict";</code> eingeführte modernere Modus definiert das übergeordnete Objekt unterschiedlich:
<syntaxhighlight lang="javascript" style="border: none; margin-left: 2em;">
 function free1 () {
    return this;
 }
 function free2 () {
    "use strict";
    return this;
 }
 window.free3 = function () {
    "use strict";
    return this;
 };
</syntaxhighlight>
Rückgabewerte bei korrekter Implementierung im Browser:
# <code>window</code>
# <code>undefined</code>
# <code>window</code>


''Innerhalb einer Funktion'' ist <code>this</code> im Regelfall der Aufrufkontext und damit –&nbsp;anders als in anderen Programmiersprachen&nbsp;– nicht immer die Vererbung zur Zeit der Definition.

Ist eine Funktion Komponente eines Objekts, verweist <code>this</code> zunächst auf dieses Objekt:
<syntaxhighlight lang="javascript" style="border: none; margin-left: 2em;">
  var obj = { prop: 42 };
  obj.fun = function () {
     alert(obj.prop);
     alert(this.prop);
  };
  obj.fun();
</syntaxhighlight>
In beiden Fällen wird <code>42</code> ausgegeben.

Das hilft insbesondere bei Bibliotheksfunktionen und Anwendungsobjekten, da das nächstübergeordnete Objekt geerbt werden kann und andere Variablen und Funktionen nicht aktualisiert werden müssen, wenn sich etwas an der höheren Objektstruktur ändert. Bei mittels <code>.prototype</code> definierten Klassenobjekten verweist <code>this</code> auf die einzelne Instanz bei Definition.&nbsp;– Allerdings ist damit auch das Ende der Vererbung in JavaScript erreicht.

Dies hat jedoch einige Tücken, wenn die Funktion als “event handler” benutzt wird. In diesem Fall wird <code>this</code> das auslösende Element. Wird die Funktion etwa in einem [[Wikipedia:Technik/Skin/JS/jQuery|jQuery]]-Aufruf angegeben, so wird hier der Funktionsrumpf in einer jQuery-eigenen Struktur gespeichert. Aus
<syntaxhighlight lang="javascript" style="border: none; margin-left: 2em; padding: 0;">
 jQuery(document).ready(obj.fun);
</syntaxhighlight>
wird intern etwas wie
<syntaxhighlight lang="javascript" style="border: none; margin-left: 2em; padding: 0;">
 jQuery17108507570563352369 = function () {
    alert(obj.prop);
    alert(this.prop);
 };
</syntaxhighlight>
Wenn dann das Ereignis <code>document ready</code> eintritt, wird aufgerufen:
<syntaxhighlight lang="javascript" style="border: none; margin-left: 2em; padding: 0;">
 jQuery17108507570563352369();
</syntaxhighlight>
Hier greift <code>this.prop</code> ins Leere; die erste Meldung ist erfolgreich, die zweite liefert <code>undefined</code>. Inhalt von <code>this</code> ist das <code>document</code> Standardobjekt.

Genauso wurden viele Jahre hindurch eigene Instanzen für das “global object” benutzt, wenn ein zeitgebundenes Ereignis mit <code>setTimeout()</code> usw. gestartet wird.

Werden die Elemente einer [[../jQuery#Suchergebnis auswerten|Suchabfrage mittels jQuery]] mit <code>.each()</code> analysiert, liefert <code>this</code> das jeweilige DOM-Element.

Um in einem Objekt fehlersicher und eindeutig immer auf sich selbst zuzugreifen, wird häufig vom Konstruktor aus das in anderen Programmiersprachen etwas seltsame Konstrukt definiert:
<syntaxhighlight lang="javascript" style="border: none; margin-left: 2em; padding: 0;">
 var that = this;
</syntaxhighlight>
Die Variable <code>that</code> wird dann lokal im Objekt und beschreibt unabhängig vom Aufrufkontext das Objekt selbst.


Mit den Standardmethoden <code>.call()</code> und <code>.apply()</code> sowie neuerdings <code>.bind()</code> kann die Zuweisung in Funktionsobjekten beeinflusst werden.

In den folgenden Beispielen ist ''fun'' eine Funktion.
* ''fun''<code>.apply</code>(''thisArg''[, argsArray])
* ''fun''<code>.call</code><nowiki>(''thisArg''[, arg1[, arg2[, [...]]])</nowiki>
Die Funktion ''fun'' wird ausgeführt; innerhalb von ''fun'' bekommt <code>this</code> den Wert ''thisArg'', wenn dies ein Objekt ist; ansonsten wird ein analoges Objekt gebildet. Die normale Zuordnung von <code>this</code> als Aufrufkontext wird hier aufgehoben.
* Der Unterschied zwischen <code>.apply</code> und <code>.call</code> liegt lediglich im Format der Argumentliste.
Relativ neu ist
* ''fun''<code>.bind</code><nowiki>(''thisArg''[, arg1[, arg2[, [...]]])</nowiki>
Als Ergebnis wird eine neue Funktion gebildet, die den gleichen Inhalt hat wie ''fun'', aber ein spezifiziertes <code>this</code> und die weiteren Argumente voranstellt.

== Nichts ==
Die Abfrage auf Existenz und Verwendbarkeit eines Datenelements verleitet gelegentlich zu Trugschlüssen. Was ein „leerer Wert“ wäre, ist mitunter nicht ganz so trivial wie das klassische Paar <code>true</code>/<code>false</code>.
<syntaxhighlight lang="javascript" style="margin-left:2em">
 var a  =  [ ];
 var n  =  null;
 var o  =  { };
 var s  =  "";
 var u  =  undefined;
 var v;
 var z  =  0;
</syntaxhighlight>

<div style="height: 111px; width: 333px; overflow: auto; border: solid 2px #A0A0A0; padding: 8px; margin-left: 2em;">
<syntaxhighlight lang="javascript" style="border: none; font-size: 85%; line-height: 80%;">
if (a) {
    window.alert("a: WAHR="+a);
 } else {
    window.alert("a: FALSCH="+a);
 }
 if (n) {
    window.alert("n: WAHR="+n);
 } else {
    window.alert("n: FALSCH="+n);
 }
 if (o) {
    window.alert("o: WAHR="+o);
 } else {
    window.alert("o: FALSCH="+o);
 }
 if (s) {
    window.alert("s: WAHR="+s);
 } else {
    window.alert("s: FALSCH="+s);
 }
 if (u) {
    window.alert("u: WAHR="+u);
 } else {
    window.alert("u: FALSCH="+u);
 }
 if (v) {
    window.alert("v: WAHR="+v);
 } else {
    window.alert("v: FALSCH="+v);
 }
 if (x) {
    window.alert("x: WAHR="+x);
 } else {
    window.alert("x: FALSCH="+x);
 }
 if (z) {
    window.alert("z: WAHR="+z);
 } else {
    window.alert("z: FALSCH="+z);
 }
</syntaxhighlight>
</div>
ergibt
       a: WAHR=
       n: FALSCH=null
       o: WAHR=[object Object]
       s: FALSCH=
       u: FALSCH=undefined
       v: FALSCH=undefined
       **** x is not defined **** Syntaxfehler
       z: FALSCH=0
* ''Object:'' Um sicher auf eine Komponente eines von außen kommenden mutmaßlichen Objekts zugreifen zu können, müssen zwei Bedingungen erfüllt sein:
*# <syntaxhighlight lang="javascript" inline>typeof o === "object"</syntaxhighlight>
*# Nicht <syntaxhighlight lang="javascript" inline>null</syntaxhighlight>
*: Üblicherweise wird das in der Abfrage zusammengefasst:<br /><syntaxhighlight lang="javascript" inline>if (o  &&  typeof o === "object") {</syntaxhighlight><br />Nur dann lässt sich ohne Laufzeitfehler <syntaxhighlight lang="javascript" inline>o.x</syntaxhighlight> auswerten.<ref name="ltr" />
* ''String:'' In JavaScript ist die leere Zeichenkette Nichts. Das ist anders als in anderen Programmiersprachen, wo jede Zeichenkette ein allokiertes Objekt darstellt, selbst wenn der Inhalt die Länge Null hat.
* ''Array:'' Im Gegensatz dazu ist ein leeres Array allokiert und liefert Nicht-Null, wie auch das Objekt ohne eigene Elemente.
* Die Funktion [[Wikipedia:Technik/Skin/JS/jQuery#jquery.isEmpty()|jquery.isEmpty()]] im Modul [[Wikipedia:Technik/Skin/JS/jQuery#jquery.mwExtension|jquery.mwExtension]] stellt auch leeres Array&nbsp;[] oder Objekt&nbsp;{} fest, nebst Basistypen.
* <code>undefined</code> ./. <code>null</code><br />Zwei Fälle sind zu unterscheiden:
*# Strikter oder typgebundener Vergleich greift nur bei exakter Übereinstimmung:
*#* <syntaxhighlight lang="javascript" inline>x === undefined</syntaxhighlight>
*#* <syntaxhighlight lang="javascript" inline>x === null</syntaxhighlight>
*# Einfacher Vergleich mit Typkonversion
*#* <syntaxhighlight lang="javascript" inline>x == undefined</syntaxhighlight><br />entspricht<br /><syntaxhighlight lang="javascript" inline>(x === undefined  ||  x === null)
</syntaxhighlight>

== Siehe auch ==
* [[mw:Manual:Coding conventions/JavaScript #Globals]]

== Anmerkungen ==
<references>
<ref name="ltr">
In JavaScript werden die Ausdrücke von links nach rechts abgearbeitet; die <code>&&</code>-Verknüpfung bricht ab, sobald ein Wert ''falsch'' angetroffen wird. So sollte es zumindest sein.
* Wäre zu befürchten, dass <code>o</code> [[#undeclared|undeklariert]] sein kann, muss zuerst über &nbsp; <syntaxhighlight lang="javascript" style="white-space:nowrap" inline>typeof o === "object"</syntaxhighlight> &nbsp; gesichert werden, dass <code>o</code> existiert, bevor <code>o</code> (auf Nicht-null) geprüft werden kann.
* Ist etwa bei einer Komponente oder lokal in einer Funktion gesichert, dass <code>o</code> immer [[#declared|deklariert]] ist, kostet die Abfrage <code>o</code> (also Nicht-<code>null</code>) weniger und würde im Fall von <code>undefined</code> oder <code>null</code> die leicht aufwändigere <code>typeof</code>-Prüfung ersparen.
</ref>
<ref name="mw.libs.cryptic">
Mit gleicher Wirkung auf kryptisch formuiert:
<syntaxhighlight lang="javascript" style="border: none; margin-left: 2em; padding: 0;">
 mw.libs.dewiki = mw.libs.dewiki || {};
</syntaxhighlight>
</ref>
<ref name="mw.libs.dewiki">
Sofern eines Tages definiert:
<syntaxhighlight lang="javascript" style="border: none; margin-left: 2em; padding: 0;">
 mw.libs.dewiki  =  { };
 window.dewiki   =  mw.libs.dewiki;
</syntaxhighlight>
Spezifische Datenelemente der deutschsprachigen Wikipedia ohne weltweite Unterstützung.
</ref>
<ref name="var1">
Siehe: [http://javascript.crockford.com/code.html#variable%20declarations crockford.com] (englisch)
</ref>
</references>

[[Kategorie:Wikipedia:Technik/Skin/JavaScript|Datenelemente]]