mit Wert von radio-buttons rechnen

[Bluefox86]

Hallo zusammen!

Ich erstelle gerade ein Formular mit unter anderem mehreren Gruppen radio-buttons.
Jedes radiobutton hat eine eigene value(eine Zahl).
Unter dem Formular ist eine Checkbox. Wenn die aktiviert wurde, soll eine Berechnung mit den Werten der radio-buttons durchgeführt werden. Die Berechnung ist eigentlich ganz einfach

(Wert Gruppe1)+(Wert Gruppe2)+(Wert Gruppe3)*(Wert Gruppe4)

Das Ergebnis dieser Berechnung soll anschliessend in einem DIV namens Ergebnis präsentiert werden.

<script type="text/javascript"><!--  
  
  
function berechnung(){  
alert( 'Vielen Dank, jetzt drücken Sie bitte auf Absenden!', '' );  
document.getElementById('ergebnis').innerHTML="HALLLOOOO"  
}  
  
//-->  
</script>

<form name="ExistenzgruenderFormular">  
<input type="radio" name="Gruppe1" value="0" checked>  
<input type="radio" name="Gruppe1" value="2">  
<input type="radio" name="Gruppe1" value="4">  
  
<input type="radio" name="Gruppe2" value="0" checked>  
<input type="radio" name="Gruppe2" value="2">  
<input type="radio" name="Gruppe2" value="4">  
  
<input type="radio" name="Gruppe3" value="0" checked>  
<input type="radio" name="Gruppe3" value="2">  
<input type="radio" name="Gruppe3" value="4">  
  
<input type="checkbox" name="einverstanden" value="1" onclick="berechnung()"> brabra  
<div id="ergebnis" style="border:1px solid black;"></div>  
</form>

Bei oben genanntem Code wird mir das alert ausgegeben (nur ein Test, ob die function überhaupt ausgeführt wird) das "HALLLOOO" in das Div geschrieben. Das funktioniert also. Nur die Versuche die values der radio-buttons zu summieren schlägt bisher immer fehl. Kann mir jemand helfen?

Vielen Dank schonmal im Voraus!
Tom

[Der Martin]

Hi,

[...] soll eine Berechnung mit den Werten der radio-buttons durchgeführt werden. Die Berechnung ist eigentlich ganz einfach
(Wert Gruppe1)+(Wert Gruppe2)+(Wert Gruppe3)*(Wert Gruppe4)

beachte, dass der Operator + in Javascript nicht eindeutig ist: Er steht sowohl für die Addition von Zahlenwerten, als auch für die Verkettung von Strings.

Nur die Versuche die values der radio-buttons zu summieren schlägt bisher immer fehl. Kann mir jemand helfen?

Die value-Eigenschaft von Formularelementen liefert in Javascript immer einen String, der Operator + wird daher als Stringverkettung interpretiert. Wandle also die Werte explizit in Zahlenwerte um.

Ciao,
 Martin

[Bluefox86]

Hallo Martin!

Danke für die schnelle Antwort!

beachte, dass der Operator + in Javascript nicht eindeutig ist: Er steht sowohl für die Addition von Zahlenwerten, als auch für die Verkettung von Strings.
Die value-Eigenschaft von Formularelementen liefert in Javascript immer einen String, der Operator + wird daher als Stringverkettung interpretiert. Wandle also die Werte explizit in Zahlenwerte um.

Das mache ich mit Number(), korrekt? Also Number(value1)+Number(value2)...

Nur wie schaffe ich es die values überhaupt anzusprechen. Da liegt mein Problem.

Kannst du mir dabei noch helfen?

[Gunnar Bittersmann]

@@Bluefox86:

nuqneH

Wandle also die Werte explizit in Zahlenwerte um.
Das mache ich mit Number(), korrekt?

Nein. Mit http://de.selfhtml.org/javascript/objekte/unabhaengig.htm#parse_float@title=parseFloat() bzw. http://de.selfhtml.org/javascript/objekte/unabhaengig.htm#parse_int@title=parseInt(). Oder auch mit - 0 oder * 1.

Nur wie schaffe ich es die values überhaupt anzusprechen. Da liegt mein Problem.

http://de.selfhtml.org/javascript/objekte/forms.htm@title=forms › http://de.selfhtml.org/javascript/objekte/elements.htm@title=elements › http://de.selfhtml.org/javascript/objekte/elements.htm#value@title=value

Qapla'

[molily]

Das mache ich mit Number(), korrekt?

Ja, kannst du.

Nein.

Wieso?

Mit http://de.selfhtml.org/javascript/objekte/unabhaengig.htm#parse_float@title=parseFloat() bzw. http://de.selfhtml.org/javascript/objekte/unabhaengig.htm#parse_int@title=parseInt(). Oder auch mit - 0 oder * 1.

Das ist wirr, du widersprichst dir selbst. Number() macht dasselbe, was die mathematischen Operatoren - und * mit ihren Operatoren als erstes machen, sie rufen ToNumber darauf auf. Warum sollte man stattdessen das kryptischere * 1 schreiben?

Zu Number vs. parseFloat und parseInt siehe auch </archiv/2010/11/t201656/#m1360727> und </archiv/2010/8/t199775/#m1345170>. parseFloat ist nur minimal anders als Number, es akzeptiert nur Dezimalwerte und erlaubt Quatsch nach der Zahl. Für das sinnvolle Parsen von hiesigen Zahlwerten ist es nur bedingt geeignet.

Mathias

[Bluefox86]

Hi,

jetzt bin ich verwirrt.

Also mit number würde gehen?

Wie würde ich das dann anwenden?

function berechnung(){  
val = Number(document.Formularname.Gruppe1.value)+ Number(document.Formularname.Gruppe2.value);  
document.getElementById('ergebnis').innerHTML=val;  
}  

Danke und liebe Grüße!

[zaphod1984]

Wie würde ich das dann anwenden?

Values von Radiobuttons auslesen ist pain in the ass, du musst die Radiobuttons über den Namen selektieren und dann drüber iterieren und überprüfen welche auf 'checked' steht.

Zum Glück hat sich da jemand schon mal Gedanken drüber gemacht:

  
var myValue = Number( $('input[name=myRadioGroup]:checked').val() )  

[zaphod1984]

;
vergessen.

[Gunnar Bittersmann]

@@zaphod1984:

nuqneH

; vergessen.

Das ist optional.

Du hast aber vergessen darauf hinzuweisen, welches Framework du gedenkst zu benutzen. Sieht nach jQuery aus.

Qapla'

[zaphod1984]

Das ist optional.

Du hast Recht, gehört aber imho zum guten Stil... :)

Du hast aber vergessen darauf hinzuweisen, welches Framework du gedenkst zu benutzen. Sieht nach jQuery aus.

Stimmt, jQuery.

[Bluefox86]

Du hast aber vergessen darauf hinzuweisen, welches Framework du gedenkst zu benutzen. Sieht nach jQuery aus.
Stimmt, jQuery.

Öhhm, und wie benutzt man ein solches Framework? Ich will doch nur die values auslesen...hätte nicht gedacht, dass da sooo viel hinter steckt...

:-(

[ChrisB]

Hi,

Values von Radiobuttons auslesen ist pain in the ass, du musst die Radiobuttons über den Namen selektieren und dann drüber iterieren und überprüfen welche auf 'checked' steht.

Das ist doch ein sehr überschaubarer kleiner Algorithmus, was soll daran ein pain in the ass sein?

Zum Glück hat sich da jemand schon mal Gedanken drüber gemacht:

var myValue = Number( $('input[name=myRadioGroup]:checked').val() )

  
Du hast dir offenbar weniger Gedanken gemacht, weil du bspw. die Information unterschlägst, dass diese Syntax die Einbindung eines speziellen Frameworks erfordert.  
  
MfG ChrisB  
  

-- 
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?

[Klawischnigg]

Hi there,

Zum Glück hat sich da jemand schon mal Gedanken drüber gemacht:

var myValue = Number( $('input[name=myRadioGroup]:checked').val() )

>   
  
Das ist kein Javascript, das ist irgendein Frameworkmist. Das $-Zeichen hat in Javascript keine Bedeutung. Ich halte es nicht für sinnvoll, nur zum Auslesen von Radiobuttonvalues 100k Frameworkmist mit irgendwelchen mystischen Funktionen mitzuladen...  
  

[molily]

Das ist kein Javascript, das ist irgendein Frameworkmist. Das $-Zeichen hat in Javascript keine Bedeutung. Ich halte es nicht für sinnvoll, nur zum Auslesen von Radiobuttonvalues 100k Frameworkmist mit irgendwelchen mystischen Funktionen mitzuladen...

»Mystisch«?! Sind wir hier nicht bei SELFHTML, wo das aufklärerische Motto »Energie des Verstehens« gilt?

Frameworks haben keine »mystischen« Funktionen, sondern sehr banale, die man beim DOM Scripting ständig braucht, etwa vernünftiges Event-Handling. Aber manche schreiben auch nach 6 Jahren noch DHTML anstatt Unobtrusive JavaScript, wo man Event-Handler ins HTML schmiert und auch sonst unorganisiert programmiert.

Mathias

[Gunnar Bittersmann]

@@molily:

nuqneH

Das ist wirr, du widersprichst dir selbst. Number() macht dasselbe, was die mathematischen Operatoren - und * mit ihren Operatoren als erstes machen, sie rufen ToNumber darauf auf. Warum sollte man stattdessen das kryptischere * 1 schreiben?

I stand corrected.

parseFloat ist nur minimal anders als Number, es akzeptiert nur Dezimalwerte und erlaubt Quatsch nach der Zahl. Für das sinnvolle Parsen von hiesigen Zahlwerten ist es nur bedingt geeignet.

Möglicherweise ist es das, was man will: Aus der Nutzereingabe "42.0815foo" die 42.0815 rauslesen. Möglicherweise will man das aber auch nicht, sondern den Nutzer auf seine falsche Eingabe hinweisen.

Qapla'

[Gunnar Bittersmann]

@@Gunnar Bittersmann:

nuqneH

Möglicherweise ist es das, was man will: Aus der Nutzereingabe "42.0815foo" die 42.0815 rauslesen.

Ah, es geht hier nicht um Eingabefelder, sondern um @value von Radiobuttons. Wer lesen kann, ist klar im Vorteil.

Qapla'

[Don P]

Hallo,

Number() macht dasselbe, was die mathematischen Operatoren - und * mit ihren Operatoren als erstes machen, sie rufen ToNumber darauf auf. Warum sollte man stattdessen das kryptischere * 1 schreiben?

Weil es kürzer ist? Aber dann doch lieber das kryptische + voranstellen, dadurch wird auch ToNumber aufgerufen. Es entfällt aber eine unnötige Rechenoperation wie bei *1 oder +0.

var x = '0.815';  
alert (typeof +x); // number

Gruß, Don P

[molily]

Weil es kürzer ist? Aber dann doch lieber das kryptische + voranstellen, dadurch wird auch ToNumber aufgerufen.

var erg = + el1.value + + e2.value + + e3.value;

Wenn jemand in meinem Team das schreiben würde, würde ich auf die Barrikaden gehen. Code sollte so sprechend wie möglich und so ausführlich wie nötig sein. Dieser Code ist vor allem schlimm. Dass es den unären +-Operator, den binären +-Operator sowie den unären ++-Operator gibt, macht die Verwirrung perfekt.

Solange man nicht beim JS1K-Contest mitmacht und sich um jeden Byte Gedanken machen muss, sind Number und parseInt/parseFloat völlig in Ordnung und machen den Braten nicht fett. Wenn man will, dass ein Minifier diese Identifier kürzt, kann man immer noch lokale Aliase anlegen.

Mathias

[Don P]

Hallo,

var erg = + el1.value + + e2.value + + e3.value;

Wenn jemand in meinem Team das schreiben würde, würde ich auf die Barrikaden gehen.

Ich auch. Dafür habe ich ja auch nicht plädiert. Es sollte dann schon so notiert werden:

var erg = (+el1.value) + (+e2.value) + (+e3.value);
Das + ist hier genauso vielsagend wie ein unnötig gesprächiges parseInt/parseFloat, ohne aber den Lesefluss unnötig zu stören bzw. den Code aufzublähen.

Allerdings erkennen parseInt/parseFloat auch in etwas wie '123müll' oder '0.815schrott' noch gültige Zahlen, der simple "+"-Operator aber nicht. Je nachdem kann das eine oder andere Verhalten erwünscht sein.
Kann mir auch vorstellen, dass parseInt/parseFloat für dieses zusätzliche Feature auch dann Rechenzeit brauchen, wenn es gar nicht nötig wäre, weil gar kein "müll" oder "schrott" vorkommen kann, wie z.B. im value eines Radiobuttons.

Solange man nicht beim JS1K-Contest mitmacht und sich um jeden Byte Gedanken machen muss, sind Number und parseInt/parseFloat völlig in Ordnung und machen den Braten nicht fett.

Das ist wohl Geschmacksache. Ich persönlich bin für immer für die kürzeste Schreibweise, solange sie verständlich ist. Ob ein Statement wie

!isNaN( erg = (+el1.value) + (+e2.value) + (+e3.value) ) || alert('Der Variablen erg wurde ein ungültiger Wert zugewiesen');

noch verständlich ist, darüber lässt sich natürlich streiten. Mich mich ist es das. JSLint ist da anderer Ansicht.

Gruß, Don P

[molily]

var erg = (+el1.value) + (+e2.value) + (+e3.value);
Das + ist hier genauso vielsagend wie ein unnötig gesprächiges parseInt/parseFloat, ohne aber den Lesefluss unnötig zu stören bzw. den Code aufzublähen.

»+« ist so vielsagend wie »Number()« oder parseInt? Das möchte ich stark bezeifeln. Der unäre +-Operator ist 90% der JavaScript-Programmierer vermutlich unbekannt. Bei »+« hätte ich als Anfänger eher die (falsche) Ahnung, dass es so etwas wie Math.abs macht. Wenn man »Number(...)« liest, muss man Number() vorher gar nicht gekannt haben, um eine Ahnung zu bekommen, was dieser Code tut. Und diese erste Ahnung »das macht wohl eine Number aus dem Wert« ist auch noch richtig. Besser lesbaren Code kann man doch nicht schreiben.

Ich persönlich bin für immer für die kürzeste Schreibweise, solange sie verständlich ist.

Verständlichkeit ist ja kein Absolutum. Für wen und in welchem Kontext, wäre die Frage. Mein Code sollte auch für diejenigen lesbar sein, die nicht die JavaScript-Coercion-Regeln im Kopf haben bzw. implizites Typecasting gewisser Operatoren kennen. Wie gesagt würde ich mir ohnehin eine Helferfunktion schreiben, die auch bspw. das Komma als Dezimaltrenner akzeptiert. Diese wäre dann in ihrer Funktionsweise und im Code gut dokumentiert.

Ob ein Statement wie
!isNaN( erg = (+el1.value) + (+e2.value) + (+e3.value) ) || alert('Der Variablen erg wurde ein ungültiger Wert zugewiesen');
noch verständlich ist, darüber lässt sich natürlich streiten.

Für mich ist es hervorragend verständlich, auch wenn ich sie aus persönlichen Präferenzen in mindestens zwei Zeilen aufsplitten würde.
Auf die Welt loslassen bzw. in einem kommerziellen Projekt verwenden würde ich diese Zeile(n) jedoch garantiert nicht.

Mathias

[Don P]

Hallo,

»+« ist so vielsagend wie »Number()« oder parseInt? Das möchte ich stark bezeifeln.

Wenn man die Wirkung kennt natürlich. Das ist Voraussetzung.

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. 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.

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. Also wenn schon auf Number() verzichtet wird, was ich eigentlich befürworte, dann einfach unär mit +. Die Erklärung ist ja dazugeliefert worden. Wer sich die merkt, kann fortan so programmieren und für den ist dann (+x) wirklich genauso vielsagend wie Number(x).

Auf die Welt loslassen bzw. in einem kommerziellen Projekt verwenden würde ich diese Zeile(n) jedoch garantiert nicht.

Warum nicht kommerziell? Wenn du nur die Funktionalität verkaufst und nicht den Code an sich für didaktische Zwecke, was spricht dann dagegen? Manche bemühen gar einen Obfuscator (grässliches Wort), damit die genaue Funktionsweise ihrer kommerzieller Programme nicht so leicht nachvollziehbar ist.

Gruß, Don P

[Der Martin]

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

[Don P]

Hallo Martin,

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

Stimmt. Die sinnvolle Wahl von Bezeichnern wird leider allzu oft vernachlässigt. Ich halte sie für extrem wichtig. Anfangs sträubte ich mich dagegen, Laufvariablen immer nur i zu nennen, wie man es überall in Programmiertutorials sieht.
Aber inzwischen habe ich eingesehen, dass das in den meisten Fällen sinnvoll ist: i ist kurz, daher unauffällig, und man merkt gleich, dass es "nur" eine Laufvaiable ist. Der Blick wird nicht abgelenkt vom eigentlich wichtigen, nämlich dem Array oder der Collection mit aussagekräftigem Namen, über die z.B. iteriert wird.

Obwohl die Benamsung durchaus auch Spass machen kann, sollte man es (außer für didaktische Zwecke) nicht übertreiben.
Wäre ich Lehrer, würde ich meinen Schülern solchen Code* zeigen:

/***************************************************/  
  
var bin = {  
  
        nochOk: 1,  
        kaputt: 0,  
        laden: -1  
  
        /*  
            Platz für weitere Zustände...  
        */  
  
    }, zwischenergebnisVonElementen = NaN;  
  
try {  
  
    if (isNaN( zwischenergebnisVonElementen = (+element1.value) + (+element2.value) + (+element3.value) )) {  
  
        throw { wieso: 'Der Variablen \'ergebnis\' wurde ein ungültiger Wert zugewiesen.', folge: bin.kaputt };  
    };  
  
} catch (aua) {  
  
    alert  (aua.wieso);  
  
    switch (aua.folge) {  
  
        case bin.kaputt: return;  
        case bin.nochOk: break;  
        case bin.laden:  ladeWahnsinn();  
    }  
}  
  
actionMit(zwischenergebnisVonElementen);  
  
/***************************************************/

Nicht, dass ich ein Fan von try-catch wäre... das benutzt man natürlich nur, wenn's gar nicht anders geht. Insofern ist der Code nicht nachahmenswert.

Gruß, Don P

*) ist nicht erguttenbergt.

[molily]

Wenn man die Wirkung kennt natürlich. Das ist Voraussetzung.

Es ist wäre Unsinn, über die Anforderungen an »lesbaren Code« zu debattieren unter der Voraussetzung, dass der Leser bereits weiß, was der Code macht. Wer den Code bereits versteht, muss nicht noch Verständnis erwerben.

Wenn ich davon ausgehen würde, dass jeder, der meinen Code liest, die ECMAScript-Spezifikation im Kopf parat hat, dann könnte mein Code natürlich anders aussehen.
Es ist aber nicht so. Selbst für die Regulars in diesem Forum gilt das nicht. Sonst wäre meine Korrektur wertlos und deine Ergänzung ebenfalls. Sie sind aber beide wertvoll. Weil sie eben für viele Mitlesende neu sind.
Selbst für mich gilt das nicht und ich muss immer wieder im Standard nachsehen.

Ich bin Programmierer, kein Lehrer. 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.

Ich bin auch noch dabei, JavaScript zu lernen. Ich lerne jeden Tag dazu. Ich schreibe seit 10 Jahren JavaScript. Ich vergesse jeden Tag Teile und frische andere Teile auf.

Wenn jemand aus dem Team darüber stolpert und fragt, was das soll, dann erkläre ich's ihm halt, und gut.

Schreibt jemand im Team Code mit Stolperfallen, bekommt er von mir die Hammelbeine langgezogen. ;)

Auf die Welt loslassen bzw. in einem kommerziellen Projekt verwenden würde ich diese Zeile(n) jedoch garantiert nicht.

Warum nicht kommerziell?

Weil kommerzieller Code nicht von Einzelpersonen geschrieben und dann vergessen wird. Wie gesagt, ich kann nicht stillschweigend davon ausgehen, dass jemand anderes, der den Code verstehen und bearbeiten soll, dasselbe JavaScript-Wissen hat wie ich und den kryptischen Code gleichsam intuitiv verstehen kann wie eine ausführliche Variante.

Mathias

[Don P]

Hallo,

Wenn man die Wirkung kennt natürlich. Das ist Voraussetzung.

Es ist wäre Unsinn, über die Anforderungen an »lesbaren Code« zu debattieren unter der Voraussetzung, dass der Leser bereits weiß, was der Code macht. Wer den Code bereits versteht, muss nicht noch Verständnis erwerben.

Wir reden wohl aneinander vorbei. Mit lesbar mein(t)e ich wirklich für *mich* und für's *Auge* und für's *schnelle* Erkennen, worum es geht, wenn man eine Programmiersprache eigentlich "kann".

Erst kürzlich bin ich wieder auf leicht verständlichen und durchaus lesbaren Code für jedermann gestoßen, der mich aber sehr genervt hat.
Der ging, in JS übersetzt, so:

var isSuccess;  
  
if (bliBlaBlubb())  
{  
    isSuccess = true;  
}  
else  
{  
    isSuccess = false;  
}  
return isSuccess;  

OMG, was soll denn das? Zehn Zeilen Code, wo doch eine einzige kurze Zeile absolut ausreichen würde und das Auge und der Verstand nicht unnötig beschäftigt werden müssten:

return bliBlaBlubb();

Es war nicht mal in JS, sondern in einer streng typsicheren Sprache, wobei absolut klar ist, dass return nur einen booleschen Wert zurückgeben kann, sonst meckert schon die Entwicklungumgebung oder, falls man das übersieht, spätestens der Compiler. Daher besteht auch keine Gefahr, dass irgendwie unklar wäre, was bliBlaBlubb() für Werte annimmt.

Man stelle sich bildlichdie Scrollerei am Bildschirm vor angesichts von hunderten oder gar tausenden Zeilen Code, die so aussehen wie oben, während man versucht, eine komplizierte Programmlogik zu verstehen.

Das meine ich, wenn ich sage, der Code muss "lesbar" sein, ganz pragmatisch.

Number(x) nimmt mir im Vergleich zu (+x) einfach zuviel Raum ein, dafür dass es eine relativ unbedeute Funktion ist, wenn es darum geht, größere Zusammenhänge zu erfassen. Das Auge wird durch etwas wie
Number(fastnix) + Number(wichtig) * Number(naja) + Number(hammer) - Number(bledzin) einfach zu sehr mit Nebensächlichem beschäftigt.
Dagegen ist (+fastnix) + (+wichtig) * (+naja) + (+hammer) - (+bledzin) einfach viel lesbarerer, wie ich meine.

Wenn jemand aus dem Team darüber stolpert und fragt, was das soll, dann erkläre ich's ihm halt, und gut.

Schreibt jemand im Team Code mit Stolperfallen, bekommt er von mir die Hammelbeine langgezogen. ;)

Stolperfallen sind gerade zum Dazulernen hervorragend geeignet. Wenn man über etwas stolpert, das man nicht auf Anhieb begreift, dann ist man gezwungen, der Sache auf den Grund zu gehen und lernt so sehr effektiv und nachhaltig Zusammenhänge, die, wenn man sie einfach doziert bekäme, schon am nächsten Tag wieder vergessen wären...

Ich bin auch noch dabei, JavaScript zu lernen. Ich lerne jeden Tag dazu. Ich schreibe seit 10 Jahren JavaScript. Ich vergesse jeden Tag Teile und frische andere Teile auf.

Klar, so geht's mir natürlich auch: Dumm geboren, nichts dazugelernt, Hälfte vergessen ;)

Gruß, Don P

[bonzo400]

@@Bluefox86:

nuqneH

Wandle also die Werte explizit in Zahlenwerte um.
Das mache ich mit Number(), korrekt?

Nein. Mit http://de.selfhtml.org/javascript/objekte/unabhaengig.htm#parse_float@title=parseFloat() bzw. http://de.selfhtml.org/javascript/objekte/unabhaengig.htm#parse_int@title=parseInt(). Oder auch mit - 0 oder * 1.

<snip>

Wieso "Nein"?

[Gunnar Bittersmann]

@@Bluefox86:

nuqneH

<script type="text/javascript"><!--

//-->

Die HTML-Auskommentierung von JavaScript-Code ist bestenfalls unsinnig, womöglich auch falsch.

Qapla'