Seltsamer Effekt!

[eumeldeumel]

Hallo,
ich wusste nicht was ich als Thema nennen soll, aber ich blich grade auch nicht mehr durch.

Aber langsam: Ich bin Schüler, und habe im Zuge eines Projektes den Spaß am Programmieren für mich entdeckt. Also habe ich mir Grundkenntnisse in HTML und CSS beigebracht, und vor kurzem Javascript entdeckt. Also habe ich ein bisschen geübt, und im Lehrplan vorgespickelt, und bin auf Zinseszins gekommen.

Und jetzt das Problem!

Ich habe es mit folgenden Beispielen ausprobiert:

1.
Startkapital 1 Euro
Zinssatz 50%
Laufzeit 2 Jahre

Ergebnis 2.25 perfekt

2.
Startkapital 10000 Euro
Zinssatz 50%
Laufzeit 2 Jahre

Ergebnis 26010000 LOL! Da hat der doch glatt die Kommas vergessen, aber warum?
Ich hab ja nicht Punkt mit Komma verwechselt oder so.

Vielen Dank im Voraus!

Viele Grüße R.

Hier der Qelltext:

function Zinseszins() {  
  
var Kn  
var K0  
var p  
var n  
var x  
  
K0 = window.prompt("Bitte geben sie das Startkapital an!", "Ohne Waerungszeichen!")  
p = window.prompt("Bitte geben sie den Zinssatz in Prozent an!", "Bitte verwenden sie , statt . ! Kein Prozentzeichen angeben!")  
n = window.prompt("Bitte geben sie die die Anzahl der geltenden Zeitraeume an!", "Ohne Einheit!")  
  
Kn = parseInt(K0)*(1 + parseInt(p));  
  
Kn = Kn / 100;  
  
do {  
	x = x+1;  
	  
	Kn = Kn*Kn;  
  
} while (x < n);  
  
alert (Kn)  
  
}

[LX]

Du solltest x vielleicht sicherheitshalber mit "0" initialisieren (var x=0).

Außerdem verwendet JavaScript tatsächlich für Fließkommazahlen nicht ",", sondern "." - und dann brauchst Du auch nicht parseInt, sondern parseFloat, um aus dem String eine solche zu machen.

Gruß, LX

[EKKi]

Mahlzeit eumeldeumel,

Ergebnis 26010000 LOL! Da hat der doch glatt die Kommas vergessen, aber warum?

"Der" hat kein Komma vergessen - *DU* hast ihm gesagt, er solle es nicht berücksichtigen:

Kn = parseInt(K0)*(1 + parseInt(p));

Möchtest Du die Eingaben nicht lieber <http://de.selfhtml.org/javascript/objekte/unabhaengig.htm#parse_float@title=in eine Kommazahl umwandeln> lassen?

Computer sind nicht intelligent, auch nicht kreativ, vergesslich, eigensinnig oder gar bösartig ... sie tun nur das, was man ihnen vorschreibt.

MfG,
EKKi

[Gunnar Bittersmann]

@@eumeldeumel:

nuqneH

var Kn
var K0
var p
var n
var x

Du solltest Anweisungen in JavaScript immer mit Semikolon abschließen.

Das ließe sich auch als Einzeiler schreiben: var Kn, K0, p, n, x;

Die Deklaration von Variablen vor ihrer Verwendung ist in JavaScript aber überhaupt nicht nötig.

K0 = window.prompt("Bitte geben sie das Startkapital an!", "Ohne Waerungszeichen!")

Dir ist bewusst, was die Methode parseInt() tut? Warum dann „ohne Währungszeichen“? (Was man übrigens mit ä und h schreibt.) Und warum willst du nur mit ganzzahligen Beträgen rechnen? Es gibt das Pendant parseFloat().

p = window.prompt("Bitte geben sie den Zinssatz in Prozent an!", "Bitte verwenden sie , statt . ! Kein Prozentzeichen angeben!")

Dito.

Kn = parseInt(K0)*(1 + parseInt(p));
Kn = Kn / 100;

Hier hast du ein mathematisches Problem. Mach dir klar, wir man Zinsen berechnet.

do {
x = x+1;
Kn = Kn*Kn;
} while (x < n);

Wenn die Anzahl der Schleifendurchläufe im Vornherein feststeht, bietet sich die for-Schleife an, nicht die do-while-Schleife.

Zur Zinseszinsberechnung brauchst du aber gar keine Schleife. Mach dir klar, wir man Zinsen berechnet.

Qapla'

[Felix Riesterer]

Lieber Gunnar Bittersmann,

Dein Posting ist wieder einmal "fachlich hilfreich", aber...

Die Deklaration von Variablen vor ihrer Verwendung ist in JavaScript aber überhaupt nicht nötig.

Auch wenn diese Behauptung absolut der Wahrheit entspricht, so ist es doch sehr sinnvoll, solche Deklarationen durchzuführen. Gerade dann, wenn man globale und lokale Variablen bewusst einsetzen möchte (denke auch an Closures!), ist eine solche Deklaration am Anfang einer Funktion oder Methode sehr sinnvoll. In meinen Projekten habe ich immer wieder im Firebug gesehen, dass ich gelegentlich globale Variablen erzeugt habe, da ich die Deklaration am Beginn einer Methode vergessen hatte, mich aber darauf verlassen hatte, die Variable korrekt initiiert zu haben.

Es hat noch einen zweiten Vorteil: Wenn man keine besonders "sprechenden" Variablennamen benutzt, dann kann man bei der Deklaration einen Kommentar zu der Bedeutung/Verwendung der Variable notieren, um auch nach Monaten/Jahren noch zu verstehen, was das Teil tut.

Ich meine einmal irgendwo gelesen zu haben, dass es guter Schreibstil sei, wenn man (lokale) Variablen am Beginn einer Funktion deklariert, anstatt "mittendrin" plötzlich var x = irgendwas stehen zu haben.

Liebe Grüße,

Felix Riesterer.

[Gunnar Bittersmann]

@@Felix Riesterer:

nuqneH

Wenn man keine besonders "sprechenden" Variablennamen benutzt, dann […]

sollte man das ändern.

Qapla'

[Blubb]

Hallo,

Wenn man keine besonders "sprechenden" Variablennamen benutzt, dann […]
sollte man das ändern.

Ach? Du schreibst also: for(int iteratorForSomeLoopWhichIsSometimesMisusedAsTempVariable = 0; ... ?

Ich denke, dass man leserlichen Code auch ohne Halbromane als Variablen hinbekommt. Gerade, weil sich Code häufig entwickelt und man zu Beginn noch nicht weiß wofür eine Variable alles (mis)gebraucht wird oder ob sich ihre Bedeutung ändert.

Grüße

[Gunnar Bittersmann]

@@Blubb:

nuqneH

Ach? Du schreibst also: for(int iteratorForSomeLoopWhichIsSometimesMisusedAsTempVariable = 0; ... ?

Nun übertreib mal nicht.

Und für einen Schleifenindex verwende ich durchaus i. Dieses Variable dient dann aber auch ausschließlich als Schleifenindex.

weil […] man zu Beginn noch nicht weiß wofür eine Variable alles (mis)gebraucht wird

Ich glaube, dann macht man etwas falsch.

oder ob sich ihre Bedeutung ändert.

Dann auch.

Qapla'

[Blubb]

Hallo,

weil […] man zu Beginn noch nicht weiß wofür eine Variable alles (mis)gebraucht wird
Ich glaube, dann macht man etwas falsch.

Ne, das heißt Entwicklungsprozess und ist ganz natürlich. Sobald man von Trivialproblemen wegkommt,  geht das schneller als man denkt. Man kann das dann beim Review reparieren aber zwischendurch gibts dann halt solche Merkwürdigkeiten.

Grüße

[Gunnar Bittersmann]

@@Blubb:

nuqneH

weil […] man zu Beginn noch nicht weiß wofür eine Variable alles (mis)gebraucht wird
Ich glaube, dann macht man etwas falsch.
Ne, das heißt Entwicklungsprozess und ist ganz natürlich. Sobald man von Trivialproblemen wegkommt,  geht das schneller als man denkt.

Das kann ich mir bei einem sauberen Programmierstil nicht vorstellen.

Qapla'

[dedlfix]

Hi!

weil […] man zu Beginn noch nicht weiß wofür eine Variable alles (mis)gebraucht wird
Ich glaube, dann macht man etwas falsch.
Ne, das heißt Entwicklungsprozess und ist ganz natürlich. Sobald man von Trivialproblemen wegkommt,  geht das schneller als man denkt. Man kann das dann beim Review reparieren aber zwischendurch gibts dann halt solche Merkwürdigkeiten.

Das ist doch keine allgemeine Gesetzmäßigkeit sondern persönliche Schlamperei eines Einzelnen. Natürlich ist niemand so perfekt, alles genau im Voraus zu planen. Änderungen ergeben sich manchmal aus der Erkenntnis, dass was nicht geht wie geplant, oder aus äußerem Anlass. Dann muss man auch dranbleiben, die Änderungen sorgfältig einarbeiten und in dem Fall der Variablenbenennung zu einem Werkzeug greifen, mit dem eine Umbenennung auf einfache Weise erledigt werden kann.

Lo!

[Blubb]

Hallo,

weil […] man zu Beginn noch nicht weiß wofür eine Variable alles (mis)gebraucht wird
Ich glaube, dann macht man etwas falsch.
Ne, das heißt Entwicklungsprozess und ist ganz natürlich. Sobald man von Trivialproblemen wegkommt,  geht das schneller als man denkt. Man kann das dann beim Review reparieren aber zwischendurch gibts dann halt solche Merkwürdigkeiten.

Das ist doch keine allgemeine Gesetzmäßigkeit

Habe ich auch nicht behauptet. Jedoch passiert das meiner Erfahrung nach um so häufiger je länger ein Code wird.

sondern persönliche Schlamperei eines Einzelnen.

Richtig! Menschen machen Fehler, deshalb kann sowas vorkommen. Ganz natürlich oder? Und wenn es passiert, dass eine Variable für Daten benutzt wird, für die Sie nicht gedacht war, dann sollte man das reparieren -- schrobst du ja auch weiter unten. Ergo schützt eine wie-auch-immer geartete Bezeichnung der Variable nicht davor.

Natürlich ist niemand so perfekt, alles genau im Voraus zu planen.

Sicher? Andere Antworten hier lassen mich daran zweifeln.

Grüße

[dedlfix]

Hi!

Das ist doch keine allgemeine Gesetzmäßigkeit
Habe ich auch nicht behauptet. Jedoch passiert das meiner Erfahrung nach um so häufiger je länger ein Code wird.

Schon klar, aber es war sehr allgemein formuliert.

Natürlich ist niemand so perfekt, alles genau im Voraus zu planen.
Sicher? Andere Antworten hier lassen mich daran zweifeln.

Die tun nur so. Die wollen nur spielen.

Lo!

[dedlfix]

Hi!

Ich meine einmal irgendwo gelesen zu haben, dass es guter Schreibstil sei, wenn man (lokale) Variablen am Beginn einer Funktion deklariert, anstatt "mittendrin" plötzlich var x = irgendwas stehen zu haben.

Das ist genauso pauschal unsinnig wie eine Funktion stets erst am Ende zu verlassen und Returnwerte bis nach hinten durchzuschleifen, anstatt einfach ein return zu notieren. Sinnvoll ist es, Variablen vor der Erstverwendung überhaupt mit einem definierten Wert zu versehen.

In meinen Projekten habe ich immer wieder im Firebug gesehen, dass ich gelegentlich globale Variablen erzeugt habe, da ich die Deklaration am Beginn einer Methode vergessen hatte, mich aber darauf verlassen hatte, die Variable korrekt initiiert zu haben.

Das Am-Anfang-Notieren kann man aber ebensogut mal vergessen haben wie das Notieren eines var, wenn die Variable erst mitten im Code erstmalig Verwendung findet. Die Übersicht zu behalten schafft man besser mit Aufmerksamkeit und Sorgfalt anstatt mit Prinzipien, die man aus Versehen nicht eingehalten hat.

Lo!

[Matti Mäkitalo]

Hi,

Ich meine einmal irgendwo gelesen zu haben, dass es guter Schreibstil sei, wenn man (lokale) Variablen am Beginn einer Funktion deklariert, anstatt "mittendrin" plötzlich var x = irgendwas stehen zu haben.

Das ist genauso pauschal unsinnig wie eine Funktion stets erst am Ende zu verlassen und Returnwerte bis nach hinten durchzuschleifen, anstatt einfach ein return zu notieren. Sinnvoll ist es, Variablen vor der Erstverwendung überhaupt mit einem definierten Wert zu versehen.

Zumindest ist es in JavaScript aufgrund des Funktionsscopes von Variablen nicht schädlich, Variablen am Anfang zu definieren. Aber ob es die Übersichtlichkeit erhöht, wage ich mal zu bezweifeln.

Bis die Tage,
Matti

[dedlfix]

Hi!

Zumindest ist es in JavaScript aufgrund des Funktionsscopes von Variablen nicht schädlich, Variablen am Anfang zu definieren. Aber ob es die Übersichtlichkeit erhöht, wage ich mal zu bezweifeln.

Es scheint, meine Aussage hatte Missverständnispotential. Mir ging es um die Sinnhaftigkeit einer pauschalen Handlung. Dass Variablen vor ihrer Verwendung initialisiert werden sollten und für Javascript im Besonderen das "var" für den Scope wichtig ist, steht für mich außer Frage. Nur die Art und Weise, wie das am besten geschieht, möchte ich ungern mit einer pauschalen Festlegung versehen wissen.

Lo!

[Kai345]

[latex]Mae  govannen![/latex]

Ich meine einmal irgendwo gelesen zu haben, dass es guter Schreibstil sei, wenn man (lokale) Variablen am Beginn einer Funktion deklariert, anstatt "mittendrin" plötzlich var x = irgendwas stehen zu haben.

Es ist zumindest eine gute Idee, um unerwünschte Effekte zu verhindern. Suchwort »Hoisting«

Ein Beispiel, das ich dazu gerade gefunden habe:

var foo = "bar";  
  
function foobar() {  
    alert(foo);     // "undefined" und NICHT wie vielleicht erwartet "bar"!!  
    var foo = "baz";  
    alert(foo);     // "baz"  
}  
foobar();  

Stur lächeln und winken, Männer!
Kai

[molily]

Ich meine einmal irgendwo gelesen zu haben, dass es guter Schreibstil sei, wenn man (lokale) Variablen am Beginn einer Funktion deklariert, anstatt "mittendrin" plötzlich var x = irgendwas stehen zu haben.

Zumindest propagiert Douglas Crockford das in seinen »Good Parts« und in JSLint. Der Hintergrund ist das angesprochene Hoisting von Variablendeklarationen, welches zu Verwirrungen führen kann. (Aus demselben Grund lehnt er Funktionsdeklarationen gänzlich zugunsten von Funktionsausdrücken ab.) Diese klare Regel soll, wie du auch sagst, zudem dazu führen, dass man das Deklarieren lokaler Variablen nicht vergisst. Ein Argument dagegen hat dedlfix schon genannt.

Guter Schreibstil ist insofern Ansichtssache. Man kann Hoisting auch als Feature verwenden, wenn man es einmal verstanden hat. Eine Variable erst bei ihrer Benutzung zu deklarieren, erlaubt es ferner, in sich geschlossene Codeblöcke ohne Beachtung der verwendeten Variablen herumzuschieben. Andererseits sollte eine Single-Purpose-Methode ohnehin nie so lang sein, dass zwischen Variablendeklarationen am Anfang und der Verwendung viel Code steht. Man sollte die Variablendeklarationen immer im Blick haben.

Mathias

[eumeldeumel]

OkOk!
Ich weiß, dass Computer dumm sind.
Ich habe mir das Kapitel über parseFloat() jetzt ein paar mal durchgelesen, und hab ein bisschen experimentiert, aber: Nichts!
Kann mir also einfach bitte jemand sagen, wo ich das parseFloat() hinsetzen soll, denn mit dem Beispiel auf selfhtml.org konnte ich wenig anfangen.
Wenn ich ein Beispiel habe, bei dem ich den Sinn im Programm sehe, lerne ich auch mehr dabe.

sorry! für die Aufregerei, ned bös gemeint ;-)

viele Grüße R.

[EKKi]

Mahlzeit eumeldeumel,

Ich habe mir das Kapitel über parseFloat() jetzt ein paar mal durchgelesen,

Und auch verstanden?

und hab ein bisschen experimentiert, aber: Nichts!

Wie: nichts!? Das kann ich nicht ganz glauben.

Kann mir also einfach bitte jemand sagen, wo ich das parseFloat() hinsetzen soll,

Was genau macht denn hier Deiner Meinung nach die Funktion http://de.selfhtml.org/javascript/objekte/unabhaengig.htm#parse_int@title=parseInt()?

Kn = parseInt(K0)*(1 + parseInt(p));

Wäre es *an genau der Stelle* nicht erheblich sinnvoller, den eingegebenen Wert in eine Kommazahl umzuwandeln?

Wenn ich ein Beispiel habe, bei dem ich den Sinn im Programm sehe, lerne ich auch mehr dabe.

Das Beispiel hast Du doch selbst vorgegeben - Du musst es lediglich korrigieren, damit es auch das tut, was Du erwartest ...

MfG,
EKKi

[Gunnar Bittersmann]

@@EKKi:

nuqneH

Kn = parseInt(K0)*(1 + parseInt(p));

Wäre es *an genau der Stelle* nicht erheblich sinnvoller, den eingegebenen Wert in eine Kommazahl umzuwandeln?

Nein, an *anderer*. ;-)

Qapla'

[EKKi]

Mahlzeit Gunnar Bittersmann,

Nein, an *anderer*. ;-)

Jaja ... nun lass den eumeldeumel doch erstmal den ersten Schritt vor dem zweiten machen, bevor Du mit dem dritten um die Ecke kommst. :-P

MfG,
EKKi

[Gunnar Bittersmann]

@@eumeldeumel:

nuqneH

Kann mir also einfach bitte jemand sagen, wo ich das parseFloat() hinsetzen soll

An den Stellen, wo du vorher parseInt() verwendet hattest.

Oder doch besser anders. Den vom Nutzer eingegeben String brauchst du nicht, also gleich den numerischen Wert daraus auslesen:

K0 = parseFloat(window.prompt("Bitte geben sie das Startkapital an!", "Ohne Waerungszeichen!"));

Bei Methoden des window-Objekts ist die Angabe desselben nicht erforderlich; parseFloat() tut dasselbe wie window.parseFloat(), prompt() dasselbe wie window.prompt(), alert() dasselbe wie window.alert().

Es ist nicht wirklich Sinnvoll, „Ohne Waerungszeichen!“ ins Eingabefeld zu schreiben, nicht einmal richtig geschrieben. Wenn dann sollte der Hinweis mit in der Aufforderung stehen.

Und „Sie“ groß, BTW:

K0 = parseFloat(prompt("Bitte geben Sie das Startkapital an (ohne Währungszeichen)!"));

Aber da du dich inzwischen über parseInt() und parseFloat() informiert hast, weißt du, dass das sowieso Quatsch ist, weil der Nutzer durchaus ein Währungszeichen hinter die Zahl setzen kann.

Qapla'