Hallo,
Jetzt war ich soooo stolz auf meine geniale Lösung, und du machst sie dermaßen runter. Das ist ja starker Tobak.
ja, es ist wenig einfühlsam - aber irgendwie trotzdem treffend.
Aber von Eleganz im Programmcode scheinen wir gänzlich unterschiedliche Vorstellungen zu haben.
Scheint so.
Man *muss* nicht, aber es ist eben eleganter in meinen Augen, weil kompakt mit wenig Quellcode.
Nee, hast du mal den Quellcode angesehen, der sich hinter den von dir aufgerufenen Funktionen verbirgt? Der gehört natürlich mitgerechnet!
"a||[]" ist kein Trick, sondern ein elegantes Konstrukt, das absichtlich in JavaScript implementiert wurde. Es ist die Abkürzung für
if (a) { return a; }
else{ return new Array(); }
Danke, das war auch mir nicht ganz klar. Die Array-Klammern [] ohne Operand davor sahen für mich ziemlich verunglückt aus; mir war nicht bekannt, dass Javascript auf diese Weise auch anonyme Arrays kennt.
Warum sollte man auf solchen "Sugar" verzichten, nur weil viele nicht wissen, wie der || -Operator funktioniert? Der funktioniert überall gleich in JavaScript (auch JS), entsprechend der ECMAScript Spezifikation.
Der war mir geläufig, aber die alleinstehenden Klammern dahinter habe ich beim ersten Lesen als Bullshit eingeordnet.
Und noch etwas: Der vermeintliche Zeitgewinn mit nur Zahlen ist in JavaScript nicht besonders groß, wenn es um Integer-Werte geht, wie in diesem Fall. JavaScript kennt nämlich überhaupt kein Integer, sondern nur 32Bit Floatingpoint. D.h. auch das Rechnen mit ganzen Zahlen passiert intern immer im Floatingpoint-Format.
Ja, das habe ich auch schon manchmal verflucht.
Wir haben halt unterschiedliche Vorstellungen von Eleganz. Was du meinst ist Schnelligkeit, Effizienz zur Laufzeit oder was immer.
So würde ich Eleganz bei Programmcode auch sehen.
Ich dagegen meine Übersichtlichkeit u. Schlankheit im Code.
Ich auch. Und das ist kein Widerspruch zum vorherigen Satz: Funktionsaufrufe, die viel Code implizieren, sind diesem Ideal für meine Begriffe abträglich.
Rekursion frisst immer etwas mehr Speicher usw., ist aber eben eleganter, weil derselbe Code einfach wiederverwendet werden kann.
Einverstanden - mir geht es auch, genau wie Daniel, nicht um die Rekursion und den damit verbundenen Stackbedarf, sondern um die Menge an zusätzlichem Code, die sich hinter einem unscheinbaren Funktionsaufruf versteckt.
So long,
Martin
Wissen erwirbt man, indem man immer das Kleingedruckte sorgfältig liest.
Erfahrung bekommt man, indem man das nicht tut.