This here at the top is not directly related to the code not working. It's more, "I hate seeing code like this, so please don't become another programmer that does it."
However, it is indirectly related, as you'll see by another problem with the code.
Initialize variables ASAP, and
once, within each highest scope possible (in this code, just once for each).
Code:
openingBalance = prompt("Please enter your opening balance");
...
openingBalance = parseFloat(openingBalance);
openingBalance = (openingBalance + depositAmount);
openingBalance = parseFloat(openingBalance);
...
openingBalance = parseFloat(openingBalance);
Here's what the code taking the initial variables aught to look something like:
Code:
firstName = prompt("Please enter your first name");
lastName = prompt("Please enter your last name");
fullName = (firstName + ES + lastName);
openingBalance = prompt("Please enter your opening balance");
openingBalance = parseFloat(openingBalance);
Doing that, you don't need to worry about calling parseFloat anywhere else, for that variable. It gets taken care of very close to the input code itself (prompt()).
You can probably wrap them together, but that's more of a style thing:
Code:
openingBalance = parseFloat( prompt( "Please enter your opening balance") );
I haven't done much JS in awhile, so if that doesn't work...()
Right after you take the input, turn it into the relevant number format (which, for any real use, should be integer or fixed-point). OK, now that's not why it isn't working, but that can help clean your code up, and help in the long run, make it easier to read, easier to spot problems, and easier to catch exceptions that occur later on in the program.
OK, now on to the functional problem(s). As you'll see, the functional problems and style problems are not unrelated.
Look at this:
Code:
[b]if[/b] [COLOR="Green"]([/COLOR]userInput [COLOR="DarkOrange"]===[/COLOR] "D"[COLOR="Green"])[/COLOR] [COLOR="Blue"]{[/COLOR]
depositAmount [COLOR="DarkOrange"]=[/COLOR] prompt[COLOR="Green"]([/COLOR]"Enter the amount of your deposit"[COLOR="Green"])[/COLOR];
[COLOR="Blue"]}[/COLOR]
[b]else if[/b] [COLOR="Green"]([/COLOR]depositAmount [COLOR="DarkOrange"]<[/COLOR] 0[COLOR="Green"])[/COLOR] [COLOR="Blue"]{[/COLOR]
alert[COLOR="Green"]([/COLOR]"Amount less than zero! Enter amount again!"[COLOR="Green"])[/COLOR];
[COLOR="Blue"]}[/color]
...lines that shouldn't be out here on their own...
See anything wrong? Notice how it stands right out, with good indentation (also, the above should help show why syntax highlighting text editors are the way to go)? White space is not enforced in most languages, because the width of a tab was never sufficiently standardized. That doesn't mean it is not exceptionally important.
The top level should be something like:
Code:
if (userInput === "D") {
1. Get input value.
2. Convert and verify value.
3. Do stuff with value.
4. Respond/return stuff.
}
else if (userInput === "W") {
1. Get input value.
2. Convert and verify value.
3. Do stuff with value.
4. Respond/return stuff.
}
else if (userInput === "B") {
Respond/return current balance only.
}
[B]else {
Bad input. Handle it here.
}[/B]
The deposit value code goes
inside the block for which userInput === "D" is true, not in parallel after it. You did the same with withdrawal and balance. Also, the bolded is missing.
When correctness may be at stake, always follow out all logical paths. Even if a user shouldn't be able to enter an invalid value, you still want to make sure it is within the set of valid inputs. Not doing so can make for serious reliability and security problems.
The full version of the quoted and colored code should instead look like:
Code:
[b]if[/b] [COLOR="Green"]([/COLOR]userInput [COLOR="DarkOrange"]===[/COLOR] "D"[COLOR="Green"])[/COLOR] [COLOR="Blue"]{[/COLOR]
depositAmount [COLOR="DarkOrange"]=[/COLOR] prompt[COLOR="Green"]([/COLOR]"Enter the amount of your deposit"[COLOR="Green"])[/COLOR];
depositAmount [COLOR="DarkOrange"]=[/COLOR] parseFloat[COLOR="Green"]([/COLOR]depositAmount[COLOR="Green"])[/COLOR];
[b]if[/b] [COLOR="Green"]([/COLOR]depositAmount [COLOR="DarkOrange"]<[/COLOR] 0[COLOR="Green"])[/COLOR] [COLOR="Blue"]{[/COLOR]
alert[COLOR="Green"]([/COLOR]"Amount less than zero! Enter amount again!"[COLOR="Green"])[/COLOR];
[COLOR="Blue"]}[/COLOR]
[COLOR="Purple"]// why allow a $0.00 deposit?
// oh, and how they going to enter it again, without a loop?[/COLOR]
[COLOR="Purple"]// openingBalance should have been handled above this, already. Omitting it.
// re-using openingBalance is bad practice.[/COLOR]
var resultingBalance [COLOR="DarkOrange"]=[/COLOR] [COLOR="Green"]([/COLOR]openingBalance [COLOR="DarkOrange"]+[/COLOR] depositAmount[COLOR="Green"])[/COLOR];
document.write[COLOR="Green"]([/COLOR]"With the deposit, your balance is now" [COLOR="DarkOrange"]+[/COLOR] ES [COLOR="DarkOrange"]+[/COLOR] resultingBalance [COLOR="DarkOrange"]+[/COLOR] BR[COLOR="Green"])[/COLOR];
[COLOR="Blue"]}[/COLOR]
You should also be able to implement the last two lines as something like this, removing the need for the assignment line in the first place:
Code:
document.write[COLOR="Green"]([/COLOR]"With the deposit, your balance is now" [COLOR="DarkOrange"]+[/COLOR] ES [COLOR="DarkOrange"]+[/COLOR] [COLOR="Green"]([/COLOR]openingBalance [COLOR="DarkOrange"]+[/COLOR] depositAmount[COLOR="Green"])[/COLOR] [COLOR="DarkOrange"]+[/COLOR] BR[COLOR="Green"])[/COLOR];
Now, the million-dollar question: did you jot down nicely indented pseudo-code, or at all diagram input->processing->output paths? We humans are fallible, and evolved to work in the physical world. Do not underestimate the power of writing things down, rather than just jumping into code. Understand the design, and follow every possible predicate after a[n externally exposed] state change (often a small number of good ones, and then a catchall for bad inputs). You need to understand what the design should be doing, as a control and/or data flow network or graph.
Note that if you want to handle bad inputs to the number values, you'll want to make a function that loops over the input routine, for your sanity, and apply it to every number to be given by the user, with the ability to return a good value, cancel the current action or whole program, or pop back up with a blank field if given an invalid input (parseFloat fails).
Are there any less involved ways of catching bugs?
See above. I was working on the reply before your edit, which I assume is when you added that, because I don't recall seeing it at first. Personally, I'd stop at a syntax-highlighting and block-aware text editor (IE, that can fold blocks, and detect unclosed blocks), for such basic Javascript.
Facebook
Twitter