Hi,
Mein Code sollte auch für diejenigen lesbar sein, die nicht die JavaScript-Coercion-Regeln im Kopf haben bzw. implizites Typecasting gewisser Operatoren kennen.
Verstehe. Für meinen Code gilt das nicht. Ich bin Programmierer, kein Lehrer.
genau diese Unterscheidung wäre für mich auch einer der wenigen Gründe, meinen Code "umständlicher" zu schreiben als nötig - wenn er für didaktische Zwecke verwendbar sein soll.
Mein Code muss rund laufen und v.a. für mich verständlich sein (das auch noch nach Jahren) und erst in zweiter Linie auch für andere, die dann aber JS nicht erst noch am Lernen sind. Wenn jemand aus dem Team darüber stolpert und fragt, was das soll, dann erkläre ich's ihm halt, und gut.
ACK. Natürlich muss man auch im Hinterkopf behalten, dass mal jemand anders das Projekt "erbt" und daran weiterarbeiten muss. Da setze ich dann aber auch voraus, dass derjenige über entsprechende Kenntnisse und Erfahrungen verfügt. Und unter diesem Aspekt halte ich es ganz genauso wie Don P: Je kompakter eine Anweisung formuliert ist, je weniger sie mit Prosa ausgeschmückt ist, umso besser. Eine sinnvolle Wahl von Bezeichnern fällt dabei ausdrücklich *nicht* unter Prosa in diesem Sinn, wohl aber die unnötig ausführliche Formulierung oder das Zwischenspeichern in Variablen, nur um einen Verarbeitungsschritt auf mehrere Anweisungen aufzuteilen.
Den unären Plus-Operator habe ich hier ja nur eingeworfen, weil eine Typumwandlung etwas unschön als Rechenoperation mit *1 bzw. +0 vorgeschlagen wurde.
Ja, und wenn er dann auch noch mit seinem Operanden geklammert wird, könnte es doch kaum klarer sein.
Auf die Welt loslassen bzw. in einem kommerziellen Projekt verwenden würde ich diese Zeile(n) jedoch garantiert nicht.
Ich schon - hier wird schließlich kein "undocumented Feature" verwendet, das in einer zukünftigen Version plötzlich anders wirken könnte.
So long,
Martin
Schildkröten können mehr über den Weg berichten als Hasen.
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(