Forum:@Technik-Kamele: Javascript aufräumen

Forum > @Technik-Kamele: Javascript aufräumen

Hinweis: Dieser Fred wurde seit 4931 Tagen nicht bearbeitet. Dieser Fred ist offiziell versandet - die Diskussion damit Geschichte. Bitte nichts mehr hinzufügen.
Bei Bedarf dann halt einen neuen Fred starten oder diesen notfalls reanimieren.

Moin moin,

in der Kamelopedia haben sich ja inzwischen so einige Javascripts angesammelt.

Insbesondere, da wir da auch zu mehrt dran basteln, habe ich so die Befürchtung, dass uns das irgendwann um die Ohren fliegt, einfach weils zu unübersichtlich geworden ist, oder weil derjenige, der den Code verzapft hat, die Herde verlassen hat (das soll ja angeblich vorkommen).

Ich habe daher zwei Vorschläge (kein entweder-oder sondern beides):

Vorschlag 1

Damit Code für Andere besser verständlich ist, sollte jede Funktion sollte mit einer Dokumentation versehen werden. Darin enthalten ist mindestens:

• ein Einzeiler, der Beschreibt, was die Funktion tut
• Beschreibung der Parameter einschließlich Angabe des Datentyps (string, integer, array etc.)
• Beschreibung des Rückgabewerts einschließlich Angabe des Datentyps

Beispiel:

/**
 * Die Funktion berechnet die Anzahl von Beinen mehrerer Kamele.
 * Parameter kamele: Anzahl der Kamele (integer)
 * Rückgabewert: Anzahl der Beine (integer)
 */
function berechne_beine(kamele)
{
    return 4 * kamele;
}

Vorschlag 2

Um zu vermeiden, dass Variablen oder Funktionennamen versehentlich doppelt benutzt werden, und klarzumachen, wozu eine Funktion / Variable überhaupt gut ist, sollten Funktionen in Modulen gruppiert werden (ähnlich wie Namespaces in C++). Dazu wird in der commons.js folgender Code platziert:

/* erzeugt ein neues Modul.
 * Parameter m: Name des zu erstellenden Moduls, kann Untermodule enthalten (String)
 * Rückgabewert: void
 *
 * Verwendungs-Beispiel:
 * 
 *     Modul("Bildsuche.Syntaxparser");
 *
 *     Bildsuche.Syntaxparser.checkSyntax = function checkSyntax( syntax )
 *     {
 *         ... Code ...
 *     }
 */
function Module(m)
{

	/*
	 * interne Funktion!
	 * erzeugt aus einem Untermodul-Array eine Modulstruktur innerhalb des containers.
	 */
	function createModule(names,container)
	{


		if (names.length == 0)
			return;

		var nextName = names.shift();
		if (container[nextName] == null)
		{
			container[nextName] = Object();
			container[nextName].parent = container;
		}
		createModule(names,container[nextName]);
	}

	createModule(m.split("."),window);
}

Zu beginn einer Javascript-Datei werden dann die Module angegeben, die die Datei benutzen will:

Module("Bildsuche.Syntaxparser");
Module("GaGA");

Dann die Funktionen / variablen dort platziert werden:

Bildsuche.Syntaxparser.irgendeineVariable = "irgendeinwert";
GaGA.irgendeineFunktion = function irgendeineFunktion () {
     return "irgendwas";
}

Jetzt weiß man gleich, wo die Funktion dazugehört. Mediawiki macht das inzwischen ja ähnlich, da ist jetzt alles im mw-Objekt drinne.

Umsetzung

Umsetzen ließe sich das ähnlich wie bei den Bild-Vervorlagungen: erstmal für neue Code-Schnipsel und auf Dauer die Altlasten beseitigen.

Grüße --J* 17:44, 10. Mai 2011 (NNZ)

Ja, die guten alten Namespaces in C++... äh, die was?

Programmiertechnich auf deinem Niveau bewandert ist hier ja nur ein verschwindend geringer Teil der Herde, und so gerne ich dir und deinem geschliffenen Code auch hinterhertrabe ... folgen kann ich ihm mangels Fachwissen nur sehr schwer ;)

Vorschlag 1 mach macht komplett Sinn, und zumindest rudimentär kommentiert ist ja auch ein Haufen Kot bereits

Vorschlag 2 ist für meinen Geschmack etwas over-the-top, zumal wir uns ja auch noch damit auseinandersetzen müssen, unseren ganzen Code an den ResourceLoader und die zahlreichen neuen Resourcen (vor allem viieeel optionales jQuery-Zeuch) anzupassen bzw. durch in MediaWiki nun integriertes Zeuch zu ersetzen.

Variablen außerhalb von Funktionen (nennt man die dann global?) haben wir selbstproduzierte ja nicht wirklich viele, zudem haben wir ja haufenweise JavaScript-Code aus Common.js ausgelagert, und der Code wird nur an benötigten Stellen geladen - vermindert ja auch etwas das Chaos im Haupt-JavaScript.

Das (da wo überhaupt schon dokumentierte) Resource-Loader-Werk finde ich als Laie schon recht unzugänglich - aber toll. Da war übrigens noch was wegen Variablen, da soll man in Kuhzunft immer window.variablenname statt variablenname nutzen (schreibe ich nur, weils mir gerade einfällt wieder).

Wenn wir jetzt noch (bevor wir unseren Kram überhaupt komplett auf ResourceLoader-Syntax umgestellt haben) so ein kamelopediainternes Modul-Dingenskirchen etablieren, wird das zwar aus programmiertechnischer Sicht ziemlich erregend und wohlgeformt, aber irgendwie auch verdammt Abstrakt für den Skript-Dilettanten ...

Pures JavaScript und jQuery-Zeuch kann man sich ja recht einfach aus dem Netz zusammenschrauben. Das ganze an den ResourceLoader zu übergeben ist schon eine Hürde mehr (dem zu sagen, wovon neuer Code abhängig ist, damit er die passenden Resourcen bereitstellt) ... kommt da jetzt noch ein "Abstraktionslevel" oben drauf (kamelopediainterne Modulregistrierung und so) ... ich bin mir nicht sicher, ob außer für dich das ganze dadurch wirklich einfacher überschaubar ist ... Aber ich Grübel mal noch drüber nach ... --Nachteule 19:33, 10. Mai 2011 (NNZ)

Tut mir Leid, wenn ich manchmal etwas Fachchinesisch rede, man verblödet halt ganz schön durch's Studium – unterbrecht mich dann einfach, ja? Vorschlag 2 muss auch nicht unbedingt sein. Und window.variablenname kann auf jeden Fall nicht schaden, wenn die Variable denn global ist – das Vermeidet dann Fehler, falls die Variable (aus welchen Gründen auch immer) nicht definiert ist. (Lokale Variablen sollten auf keinen Fall so benutzt werden.) Grüße --J* 13:37, 11. Mai 2011 (NNZ)

Zu Vorschlag 1 würde ich vorschlagen, dass wir das so machen, wie DIE das vorschlagen (@usw.). Nur so als Vorschlag. --WiMu 16:02, 11. Mai 2011 (NNZ)

Ja, warum nicht --J* 16:55, 11. Mai 2011 (NNZ)