Lieber Orlok,

Wenn wir schon bei Kritik sind: Ist es für unbedarftere Leser wünschenswert, anschaulichere Beispiele zu erstellen?

Klar ist es das! :-D

prima!

Wenn ich mir mit den Beispielen noch mehr Zeit genommen hätte, dann gäbe es jetzt sicher den ein oder anderen Artikel weniger. Und damit die ein oder andere inhaltliche Lücke im Wiki mehr. ;-)

Dieses Argument lässt sich nicht widerlegen. Auch war es nicht meine Absicht, dass Du selbst anschaulichere Beispiele erstellst, sondern Deine Bereitschaft zum Abändern der vorhandenen Beispiele hin zu für Lernende anschaulichere abzufragen. Jetzt, da ich verstanden habe, dass Du prinzipiell nicht dagegen bist, kann man Dir diese Arbeit ja abnehmen. Ist ja ein Wiki.

Aber es ist nicht nur eine Frage des Zeitaufwands, sondern es ist auch immer zu berücksichtigen, welchen Zweck ein bestimmtes Beispiel erfüllen soll. Sprich, wenn es das Ziel ist irgendeine Syntax zu veranschaulichen, dann ist es meiner Meinung nach eher kontraproduktiv, wenn das Ganze in einem zu opulenten Kontext präsentiert wird. Da ist es glaube ich besser, sich auf das Wesentliche zu beschränken.

Das ist sicherlich richtig. Und wenn syntaktische Extras im Code sind, kann man diese ja unter dem Code-Beispiel ansprechen und auf die jeweiligen Erläuterungen dazu im Wiki verlinken.

Denn darüber hinaus ist schließlich auch immer zu berücksichtigen, dass man ja nie weiß, welches Vorwissen der Leser oder die Leserin besitzt. Schreibt man also ein ausführlicheres, vielleicht auch praxisnäheres Beispiel, dann lässt sich das Risiko kaum vermeiden, Sprachmittel zu verwenden, mit denen der oder die Lesende womöglich nicht vertraut ist. Also muss man dann im Begleittext noch weitere Einzelheiten des Beispiels erklären oder zumindest Erklärungen verlinken, was aber alles wieder vom eigentlichen Thema ablenkt. Und natürlich auch wieder Zeit kostet, die an anderer Stelle vielleicht besser investiert wäre.

Damit soll es nicht (unbedingt) in Deinen Aufgabenbereich fallen. Jetzt, da Du einen Artikel erstellt hast, kann man ihn "verschönern". Da Du hier ins Meta-Forum gehst, um über diesen Artikel zu berichten, kann man gleich hier an Ort und Stelle über ein "schöneres" Beispiel diskutieren.

const Affenfutter = [
    "Banane", "Samen"
];

alert(
    "Affen fressen "
    + (Affenfutter.includes("Banane") ? "gerne" : "keine")
    + " Bananen."
);
alert(
    "Affen fressen "
    + (Affenfutter.includes("Seetang") ? "gerne" : "keinen")
    + " Seetang."
);

Bevor ich näher auf diesen Punkt eingehe – bitte verzeih’ mir – kann ich nicht umhin, etwas aus einem deiner früheren Postings zu zitieren. :-D

Aus meiner Sicht ist window.alert grundsätzlich zu bekämpfen.

Mein Credo: Anfängern ist alert als giftig und strengstens zu vermeiden abzuempfehlen.

Ich weiß, ich weiß, das war gemein. ;-)

Nein, das war es nicht. Mein Beispiel war nicht genügend durchdacht und Wiki-fertig. Ist es nicht gut, dass ich es nicht sofort im Wiki eingesetzt, sondern erst hier zur Diskussion gestellt habe? So konntest Du als ursprünglicher Autor des Wiki-Artikels Deine Sichtweise anbringen und mein Beispiel zur Verbesserung vorschlagen.

Aber eigentlich finde ich, dass du damit recht hattest, denn gerade Anfänger, die das Wiki zum Lernen benutzen, sollten so früh wie möglich lernen, dass es eine Konsole gibt und wie und wofür man sie verwenden kann. Einen Artikel der sich damit befasst gibt es ja. Dieser sollte am besten in jedem Artikel der in den Beispielen die Konsole verwendet auch verlinkt werden. Dass ich das bislang nicht konsequent getan habe ist ein Fehler.

Ersetze "Fehler" mit "Unvollständigkeit". Das klingt weniger schlimm. Vor allem am Anfang des Artikels könnte ein Hinweis stehen, dass viele der Code-Beispiele die Konsole des Browsers zur Ausgabe nutzen. Fertig.

Darüber hinaus möchte ich jedoch zu bedenken geben, dass ich in meinen Beispielen durchaus versuche, auf die üblichen Verdächtigen foo, bar und baz zu verzichten. ;-)

+1

Davon abgesehen, habe ich mir angewöhnt die Codebeispiele grundsätzlich in Englisch zu verfassen, dafür aber im Fließtext nach Möglichkeit keine englischen sondern deutsche Begriffe zu verwenden, wobei ich dann oft noch die englische Übersetzung in Klammern dahinter setze.

Das finde ich sehr sinnvoll. Auch ich habe mir angewöhnt meinen Code mit englischen Bezeichnern zu versehen (das war nicht immer so). Man darf nicht ausser Acht lassen, dass Software in diesen Webtechnologien grundsätzlich quelloffen ist (von obfuskiertem Code einmal abgesehen) und im internationalen Raum erreichbar ist. Insofern ist es der Natur der Sache geschuldet, wenn man sich auf englische Namen für Bezeichner besinnt.

Aber diese Entscheidung, Code grundsätzlich in Englisch zu verfassen, möchte ich natürlich niemandem aufzwingen.

Aber man kann es anregen, da es einen Sinn hat.

Und um noch etwas zu der von dir verwendeten Technik zu sagen: Strinkkonkatenation wie in deinem Beispiel ist sowas von ECMAScript 5! ;-)

const Affenfutter = ['Banane', 'Samen'];

console.info(`Affen fressen ${
  Affenfutter.includes('Banane') ? 'gerne' : 'keine'
} Bananen.`);

console.info(`Affen fressen ${
  Affenfutter.includes('Seetang') ? 'gerne' : 'keinen'
} Seetang.`);

Jau. Nu isses echt mal schöner, Mann. Aber irgendwie kommt mir das ${...} wie Bash-Syntax vor. Sicherlich hat es da auch seinen Ursprung. Und was das Code-Beispiel angeht, so hätte ich lieber eine Funktion wie sprintf in PHP. Dass es dieses in JavaScript noch nicht als Standard-Stringmethode gibt, will ich nicht einsehen. Momentan muss man sich mit einer zusätzlichen Bibliothek behelfen (sprintf für JavaScript). Selbst die Konsole kennt Parameterersetzung in Strings!

Aber das ist im Moment ohnehin ein großes Problem, da in ECMAScript 6 die Antworten auf viele Fragen nach der best practice anders ausfallen, die entsprechende Syntax in dieser Übergangsphase aber oft noch nicht zufriedenstellend unterstützt wird.

Es gäbe ja längst schon ein bewährtes Konzept... sprintf

Ich denke, gerade die Teile des Wikis in denen ich mich bislang eingebracht habe betreffen ja eher die technische Dokumentation und weniger Tutorials für Anfänger. Ich denke, da ist es dann vielleicht auch eher verzeihlich, wenn die Beispiele ein wenig sachlicher und abstrakter sind, als es in einem Anfängertutorial angebracht wäre.

Schon OK. Ich wollte in dieser Diskussion auch beispielhaft ausprobieren, inwiefern man Deine Arbeit ergänzend unterstützen kann, welche technischen Möglichkeiten sich bieten (auch anhand Deiner Einstellungen zur Thematik), und wie sich das Prinzip bewährt, dass wir Diskussionen zu Wiki-Seiten eben nicht dort, sondern in diesem Forum führen.

Da an anderer Stelle ausdrücklich davor gewarnt wird, in Sprachelemente verändernd einzugreifen, böte sich hier ein kurzer Absatz an, warum dieses Polyfill absichtlich doch dieses tut, und warum dieses Vorgehen nicht nur sinnvoll sondern wichtig ist.

Da hast du allerdings recht. – Werde sehen, dass ich die Info hinzufüge.

Dann lohnt vielleicht ein eher allgemein gehaltener Artikel zu "Polyfill"? Momentan haben wir nur etwas zu Polyfill im Glossar.

Jedenfalls, wie dem auch sei, möchte ich mich für deine konstruktive Kritik bedanken! :-)

Herzlich gerne!

Liebe Grüße,

Felix Riesterer.

Hallo Orlok,

da ich noch sehr neu bin, bin ich naturgemäß sehr vorsichtig was menschlichen Umgang angeht. Die gegenseitige Zusicherung, dass man sich nicht irgendwas übelnimmt, ist mir deshalb sehr wichtig. Danke für deine Antwort darauf.

Nochmal zum Thema :)

(1) length bei Arrays ist tatsächlich sehr verwirrend. Es gibt Array.length, konstant 1, dann Array.prototype.length, konstant 0, und dann hat jedes Array ein eigenes, ungeerbtes length-Property mit der realen Länge. Da war ich im Irrtum, ich dachte irgendwie, dass die length Eigenschaft eines Array-Objekts als Methode aus dem Prototypen kommt. Kann natürlich nicht funktionieren, das war Unsinn von mir.

(2) Das bringt mich aber auf eine andere Frage: Array.length und Kollegen, wie Object.length, Function.length, Date.length - das ist immer die Anzahl der Parameter, die die Konstruktorfunktion formal erwartet. Muss man das ausführlicher dokumentieren? Ich hätte das mit nein beantwortet.

(3) Danke für die Einordnung des Artikelanspruchs. Das hilft mir beim Abrunden meiner laufenden Überarbeitung des Objekte-Artikels (auf meiner User-Seite als Temp-Seite verlinkt, falls Du Dir das anschauen willst).

Gruß Rolf