if-else Syntax

[lypô]

hai Alle,
ich habe mir mal wegen Java Netbeans herunter geladen und es mit einer Javascript-Datei ausprobiert ... soll ja funktionieren.
Jetzt meldet mir die Überprüfungsfunktion alle Vergleiche als fehlerhaft:

if(emil==luise)...
Da sollte angeblich stehen:
if(emil===luise)...
Entsprechen für != -> !==

Ist die Schreibweise mit zwei Gleichheitszeichen im ersten Fall 'ne Vereinfachung? Funktionieren tut's auch mit dreimal =
Ich dachte immer, zweimal = wäre die richtige Syntax; steht auch überall so. Ist das nur 'ne Ungenauigkeit in Netbeans?
Danke

vG
...lypô

PS.: In der Archivsuche habe ich dazu nichts gefunden.

[Matthias Apsel]

Om nah hoo pez nyeetz, lypô!

Zwei Gleichheitszeichen prüfen auf einen gleichen Wert, drei zusätzlich auf Typgleichheit.

1 == 1.0 gibt true, 1 === 1.0 gibt false, weil eine ganze Zahl (integer) nicht typgleich zu einer reellen Zahl (float) ist.

Übrigens: NetBeans ist eine Java-Entwicklungsumgebung und Java != JavaScript

Matthias

[1UnitedPower]

1 == 1.0 gibt true, 1 === 1.0 gibt false, weil eine ganze Zahl (integer) nicht typgleich zu einer reellen Zahl (float) ist.

Nur damit hier keine Verwirrung ensteht (du hast ja bereits auf den Unterschied zwischen Java und Javascript hingewiesen):
In Javascript evaluiert 1 === 1.0 zu true.

Übrigens: NetBeans ist eine Java-Entwicklungsumgebung und Java != JavaScript

Matthias

[Der Martin]

Hallo,

1 == 1.0 gibt true, 1 === 1.0 gibt false, weil eine ganze Zahl (integer) nicht typgleich zu einer reellen Zahl (float) ist.

in Java mag das so sein.

Nur damit hier keine Verwirrung ensteht (du hast ja bereits auf den Unterschied zwischen Java und Javascript hingewiesen):
In Javascript evaluiert 1 === 1.0 zu true.

... weil Javascript den Datentyp "Number" nicht weiter differenziert. Es gibt zwar Ansätze wie parseInt() oder parseFloat(), aber deren Unterschied besteht hauptsächlich darin, was sie in dem als String vorliegenden ausgeschriebenen Zahlenwert als gültig oder nicht gültig betrachten. Das Ergebnis ist in beiden Fällen Number - nur dass es bei parseInt() "zufällig" eine Ganzzahl ist.

Es spricht auch vieles dafür, dass ein Number-Typ in Javascript intern als Ganzzahl (integer) gespeichert wird, solange das vom Wertebereich her möglich ist. Aber die Umwandlung zwischen den beiden Formaten erfolgt automatisch bei Bedarf, und als User/Programmierer hat man keinen direkten Einfluss darauf.

Ciao,
 Martin

[lypô]

1 == 1.0 gibt true, 1 === 1.0 gibt false, weil eine ganze Zahl (integer) nicht typgleich zu einer reellen Zahl (float) ist.

Nur damit hier keine Verwirrung ensteht (du hast ja bereits auf den Unterschied zwischen Java und Javascript hingewiesen):

In Javascript evaluiert 1 === 1.0 zu true.

... weil Javascript den Datentyp "Number" nicht weiter differenziert. Es gibt zwar Ansätze wie parseInt() oder parseFloat(), aber deren Unterschied besteht hauptsächlich darin, was sie in dem als String vorliegenden ausgeschriebenen Zahlenwert als gültig oder nicht gültig betrachten. Das Ergebnis ist in beiden Fällen Number - nur dass es bei parseInt() "zufällig" eine Ganzzahl ist.

Es spricht auch vieles dafür, dass ein Number-Typ in Javascript intern als Ganzzahl (integer) gespeichert wird, solange das vom Wertebereich her möglich ist. Aber die Umwandlung zwischen den beiden Formaten erfolgt automatisch bei Bedarf, und als User/Programmierer hat man keinen direkten Einfluss darauf.

Puh - jetzt wird's ganz präzise. Mit parseInt() hatte ich mal was. Das ist aber eeewig her und sooo viel programmiere ich nun auch nicht. Bald wird's sich ändern.

vG und massenhaft Dankeschön an Alle
...lypô

[lypô]

Nur damit hier keine Verwirrung ensteht (du hast ja bereits auf den Unterschied zwischen Java und Javascript hingewiesen):
In Javascript evaluiert 1 === 1.0 zu true.

Matthias

Stärke und Schwäche von JS zugleich: Die Variablen sind flexibel - in toto, also auch im Format. :-))
Wie es bei Java aussieht, will ich ja lernen. Perl und PHP stehen auch noch auf dem Programm. Ich hab mir, glaub ich, 'ne ganzen Menge vorgenommen.

vG
...lypô

Achja: Was heißt "Om nah hoo pez nyeetz, lypô!" Übersetze bitte mal. :-))

[1UnitedPower]

Achja: Was heißt "Om nah hoo pez nyeetz, lypô!" Übersetze bitte mal. :-))

Ist glaube ich die Begrüßungsformel eines Indianerstammes. Ich bin selbst nich lang genug hier um sagen zu können, wie sich das im Forum durchgesetzt hat. Würde mich aber auch mal interessieren.

[Siri]

Ist glaube ich die Begrüßungsformel eines Indianerstammes. Ich bin selbst nich lang genug hier um sagen zu können, wie sich das im Forum durchgesetzt hat. Würde mich aber auch mal interessieren.

Vulkanindianer! ;-)

[lypô]

Ist glaube ich die Begrüßungsformel eines Indianerstammes. Ich bin selbst nich lang genug hier um sagen zu können, wie sich das im Forum durchgesetzt hat. Würde mich aber auch mal interessieren.

Vulkanindianer! ;-)

Spitzohr? Jedenfalls hat's irgendwas mit Star Trek zu tun. Google gibt als erstes
http://de.memory-alpha.org/wiki/Kautschukbaumvolk
her und als drittes dann
http://www.startrekfans.net/index.php?showtopic=24182

Der Rest ist u.a. selfhtml, aber nicht nur dort wurde es zur stehenden Redensart.
Das hätte ich so nie nach geschaut. :-))

Jetzt werde ich mal hier weiter arbeiten. Ich komme bestimmt bald wieder mit weiteren Fragen...

[Der Martin]

Hi,

In Javascript evaluiert 1 === 1.0 zu true.
Stärke und Schwäche von JS zugleich: Die Variablen sind flexibel - in toto, also auch im Format. :-))

ja, kann man tatsächlich als Vorteil oder als Nachteil sehen.

Ich mag diese Art von Flexibilität nicht gern, ich hätte lieber eindeutige, feste Typen, wie ich es von C her gewöhnt bin. Die automatische Typkonvertierung führt auch sowohl in Javascript, als auch in PHP immer wieder zu bösen Fallstricken.

Beispiel: Jemand liest per JS Zahleneingaben aus zwei Formularfeldern und glaubt, er würde zwei Zahlen addieren - und wundert sich dann, warum 120+70 anscheinend 12070 ergibt. In Wirklichkeit sind es erstmal Strings, und im Ausdruck

"120" + "70"

wird der Operator '+' als Stringverkettungs-Operator angesehen, weil ja beide Operanden Strings sind. Hätte man die beiden Zahlenwerte subtrahieren wollen, wäre das Problem nicht aufgefallen, denn der Operator '-' ist für Strings nicht definiert, sondern nur für Zahlen:

"120" - "70"

Also werden die Operanden automatisch in Zahlen umgewandelt und das numerische Ergebnis ist 50. So praktisch das manchmal sein mag - ich find's heimtückisch.

Ciao,
 Martin

[lypo]

Om nah hoo pez nyeetz, lypô!

Zwei Gleichheitszeichen prüfen auf einen gleichen Wert, drei zusätzlich auf Typgleichheit.
Java != JavaScript

Matthias

1. - Ahaaaa! Merci, das wusste ich nicht. Bisher hatte es wunschgemäß funktioniert - oder auch nicht :-)).

2. - Is' mia klar. Deswegen schrieb ich ja, dass Netbeans angeblich auch Javascript prüfen kann. Und dabei stolperte ich über diese merkwürige == / === Sache. Für mich machte es bisher keinen Unterschied, da ich - tja, warum? - nur mit ganzen Zahlen arbeitete. Zufall? Naja - ja.

Also bedankt für den Tip, bei selfhtml hatte ich das noch nie gelesen.

vG
...lypô

[1UnitedPower]

Für mich machte es bisher keinen Unterschied, da ich - tja, warum? - nur mit ganzen Zahlen arbeitete. Zufall? Naja - ja.

Doch. Sicherzustellen, DASS du überhaupt mit Zahlen arbeitest, macht den Unterschied für dich aus. Ich empfehle dir nur mit dem strict-equal (===) zu arbeiten, um unangenehme überraschungen zu vermieden.

Ein Bespiel.

0 === "0" // false  
1+1; // 2  
  
0 == "0" // true  
"1"+1; //11

[lypô]

Doch. Sicherzustellen, DASS du überhaupt mit Zahlen arbeitest, macht den Unterschied für dich aus. Ich empfehle dir nur mit dem strict-equal (===) zu arbeiten, um unangenehme überraschungen zu vermieden.

Ein Bespiel.

0 === "0" // false

1+1; // 2

0 == "0" // true
"1"+1; //11

  
Ich mewinte, bisher sei es kein Unterschied gewesen, das gewünschte Ergebnis habe ich erzielt.  
  
Manchmal kann es ganz sinnvoll sein, 0 und "0" zu vergleichen. Dennoch werde ich mein Script daraufhin untersuchen - und gleichzeitig mir diese Sache merken. Vielleicht wird's ja demnächst nötig. Oder ich hatte diese Fehler schon, ohne es zu bemerken, und habe dann mangels Lösung einen anderen Weg beschritten? Ich beobachte mich mal.  
  
Dein Beispiel "1"+1 hatte ich schon, da war's mir auch klar: Das hieroglyphische Ergebnis war Hinweis genug.  
  
Danke und 'nen schönen Tag noch  
...lypô

[Vertreter vom Linksetzer]

PS.: In der Archivsuche habe ich dazu nichts gefunden.

Archiv

[lypô]

PS.: In der Archivsuche habe ich dazu nichts gefunden.

Archiv

Danke, schon klar. Ich hatte aber thematisch nichts gefunden.

[Vertreter vom Linksetzer]

PS.: In der Archivsuche habe ich dazu nichts gefunden.

Archiv

Danke, schon klar. Ich hatte aber thematisch nichts gefunden.

Bitte! In diesem Thread ist ein Link der dich http://de.selfhtml.org/javascript/sprache/operatoren.htm#vergleich@title=dahin führt. Zu unthematisch? ;-)

[lypô]

Archiv

Danke, schon klar. Ich hatte aber thematisch nichts gefunden.

Bitte! In diesem Thread ist ein Link der dich http://de.selfhtml.org/javascript/sprache/operatoren.htm#vergleich@title=dahin führt. Zu unthematisch? ;-)

Nee, nicht wirklich. Den muss ich übersehen haben. Vielleicht sollte ich selfhtml noch einmal lesen?
Danke für den Hinweis (und den kleinen Seitenhieb). :-)) Ich nehm's als Aufforderung, mein Wissen zu aktualisieren.

Auch dir dankeschön
vG
...lypô

[Vertreter vom Linksetzer]

... Ich nehm's als Aufforderung, mein Wissen zu aktualisieren.

Viel Erfolg!

[dedlfix]

Tach!

Jetzt meldet mir die Überprüfungsfunktion alle Vergleiche als fehlerhaft:

Ist das wirklich eine Fehlermeldung oder ist das nur ein Hinweis, dass du mal prüfen möchtest, eventuell statt des lascheren == das peniblere === zu verwenden?

Es gibt Situationen, da muss der Typ stimmen. Meist ist das aber unerheblich. Wenn man dann den typsicheren Vergleich schreibt, irritiert das eventuell nur den Leser, der sich fragt, warum hier auch noch der Typ geprüft wird, obwohl für den vorliegenden Anwendungsfall ohne diese zusätzliche Prüfung das Ergebnis genauso ausfällt.

dedlfix.

[1UnitedPower]

Wenn man dann den typsicheren Vergleich schreibt, irritiert das eventuell nur den Leser, der sich fragt, warum hier auch noch der Typ geprüft wird, obwohl für den vorliegenden Anwendungsfall ohne diese zusätzliche Prüfung das Ergebnis genauso ausfällt.

Ich empfinde eher den umgekehrten Weg irritierend, bei dem ich nicht sagen kann, ob der Author des Codes sich der Typen bewusst war oder nicht.

Im übrigen finde ich es kritisch von "einer zusätzliches Prüfung auf den Typen" zu sprechen. Besser man spricht vom "Auslassen von Typen-Kovertierungen/-Anpassungen". Denn der Typ muss auch bei non-strict-equal überprüft werden um festzustellen, ob eine Kovertierung vorgenommen werden soll.

[lypo]

Ah - da kam noch was hinterher; ich hab's übersehen, scusi.

Jetzt, mit etwas mehr Kenntnissen über Java, halte ich Javascript eben wegen seiner Flexibilität durchaus für eine Alternative. Bei mir war die Typprüfung nicht wichtig, da ich tatsächlich immer die gleichen Typen verglich - Zufall oder nicht, egal.

Tatsächlich sollte der Programmierer aber auch das bedenken. Da gebe ich euch beiden recht und hab's mir ja auch hinter den Spiegel - äh: Monitor - gesteckt. :-))

Danke also, 'nen schönen Tag und vor allem ein schönes WE.
vG
...lypô

[molily]

Hallo,

ich habe mir mal wegen Java Netbeans herunter geladen und es mit einer Javascript-Datei ausprobiert ... soll ja funktionieren.
Jetzt meldet mir die Überprüfungsfunktion alle Vergleiche als fehlerhaft

Viele JavaScript-IDEs haben die Prüftools JSLint oder JSHint eingebaut. Diese basieren auf den Empfehlungen aus dem Buch »JavaScript – The Good Parts« von Douglas Crockford.

Der Operator == gilt als ein Fallstrick von JavaScript, weil er zum Vergleich der Werte automatisch deren Typ umwandelt und angleicht. Die Regeln dafür kann man lernen, sind aber nicht intuitiv. Auf diese Weise kommt gerne eine Gleichheit heraus, die man nicht erwartet. Das kann zu fehlerhaften bzw. unzuverlässigen Programmen führen.

JSHint und JSLint empfehlen deshalb, ausschließlich den Operator === zu verwenden, welcher keine Typumwandlungen vornimmt und eine Identität bzw. Wert- und Typgleichheit überprüft. Dis führt zu zuverlässigerem Code. Außerdem wird der Code eindeutig. Da es keine implizite Typumwandlung gibt, müssen Sonderfälle explizit geprüft werden.

Meta-Sprachen wie CoffeeScript, die nach JavaScript kompilieren, beherzigen viele Richtlinien aus den »Good Parts«. Daher wird == automatisch zu === umgeschrieben.

Die Regel, ausschließlich === zu verwenden, ist durchaus sinnvoll. Allerdings ist automatische Typumwandlung (sowohl beim Vergleich als auch beim Umwandeln in Boolean) ein wichtiges Feature dynamischer Sprachen und ich nutze es gerne. Dass "123" == 123 true ergibt, ist in der Regel ein nützliches Feature. In vielen Fällen ist eine explizite Typprüfung nicht notwendig, weil sich aus dem Kontext der Typ ergibt bzw. keine Gefahr besteht (z.B. typeof foo == 'string'). Bei Objekten prüfen sowohl == als auch === die Identität, es gibt also keinen Unterschied. Beim Testen auf null oder undefined ist wert == undefined kürzer als wert === undefined || wert ==== null.

Bei den Regeln der »Good Parts« geht es darum, dass nicht jeder dieses Wissen hat, aber trotzdem robust programmieren soll. Daher die simple Regel, *immer* === zu verwenden, auch wenn == im Einzelfall unproblematisch oder identisch mit === sein mag.

Grüße,
Mathias