The last statement in my example code from my school book, document.write("Thank you!" + BR); is not displaying and I'm not certain why. I'm taking a course and I am using the book's sample code to practice.
I have narrowed it down to the html tags nested within the script (in the middle, not at the beginning). Although I feel the root of the problem lies with the "creating of the account object" that falls right before the, "Thank you!" statement.
Using the sandbox from danml.com, I was able to remove or comment the aforementioned html tags and the script appeared to execute in its entirety, displaying "Thank you!"
I'm certain though, that this snippet of code is needed in some form or fashion to properly execute the remaining code.
If I leave it missing, I get an error that my account deposit function is not a function.
If I put the html tags back, it stops after displaying the program's purpose and refuses to display the "Thank you!" statement.
I'm just a student, so be gentle. Here is the example code from the book:
Code:
<html>
<head>
<script type="text/javascript">
// Program name: AccountClass.html
// Purpose: Use a constructor function
// to create an object
// Author: Paul Addison
// Date last modified: 01-Sep-2011
// Constructor function for the Account class
function Account(type, num, lName, fName, bal) {
this.acctType = type;
this.acctNumber = num;
this.lastName = lName;
this.firstName = fName;
this.acctBal = bal;
// Link the current object to the class methods
this.deposit = deposit;
this.withdraw = withdraw;
this.changeName = changeName;
this.inquire = inquire;
this.displayInfo = displayInfo
} // end Account function
// Function to deposit in the account
function deposit(amt) {
this.acctBal = this.acctBal + amt
document.write("New balance: $" + this.acctBal + BR);
}
// Function to withdraw from account
function withdraw(amt) {
this.acctBal = this.acctBal - amt;
document.write("New balance: $" + this.acctBal + BR);
}
// Function to change the first and last name
function changeName(lName, fName) {
this.lastName = lName;
this.firstName = fName;
document.write("The name has been changed to " + this.fName + " " + this.lName + BR);
}
// Fucntion that returns the current balance
function inquire() {
document.write("Balance: $" + this.acctBal + BR);
}
// Function that displays all account information
function displayInfo(amt) {
document.write("Account type: " + this.acctType + BR);
document.write("Account #: " + this.acctNumber + BR);
document.write("Last name: " + this.lName + BR);
document.write("First name: " + this.fName + BR);
document.write("Balance: $" + this.acctBal + BR);
}
</script>
</head>
<body>
<script type="text/javascript">
// Variables and constants
var BR = "<br />";
// State program purpose
document.write("Account program." + BR);
document.write("This program creates an account." + BR);
var mySavingsAcct = new Account("S", 1376433, "Dunes", "Sandi", 80.00);
// Deposit $100
mySavingsAcct.depost(100.00);
//Withdraw $50
mySavingsAcct.withdraw(50.00);
// Inquire about balance
mySavingsAcct.inquire();
// Display info for verification
mySavingsAcct.displayInfo();
// Thank the user
document.write("Thank you!!" + BR);
</script>
</body>
</html>
You misspelled deposit, your display function requires a parameter (which it actually doesn't) and document.write should never be used ... Not even, or more like especially!, for educational purposes.
If that book is required for some class, then you need to report the instructor to the school as incompetent to teach the subject, since he chose a book that is over 10 years out of date.
If you chose it yourself, then consider using it for its highest possible purpose: fire kindling.
document.write stopped being necessary with Netscape 4 and became even less advisable with MSIE 5. 1998 and 1999 or so. It is considered obsolete, bad coding, and inappropriate for modern usage (with a few very advanced exceptions).
__________________
An optimist sees the glass as half full.
A pessimist sees the glass as half empty.
A realist drinks it no matter how much there is.
Actually, it was easy to find. I loaded his code into Notepad and then tried to save it. Notepad complained because it found Unicode characters and I was trying to save to ASCII test file. So I told it to go ahead and save anyway, loaded the HTML into the browser, and *WHAM*. The debugger found it immediately.
I wish that JS instructors and JS books would *FIRST* teach students how to use the debugger. As part of the very first lesson. Life would be *SO* much easier for the students and we'd have maybe half the posts with such obvious errors as we get now.
__________________
An optimist sees the glass as half full.
A pessimist sees the glass as half empty.
A realist drinks it no matter how much there is.
I wish that JS instructors and JS books would *FIRST* teach students how to use the debugger. As part of the very first lesson. Life would be *SO* much easier for the students and we'd have maybe half the posts with such obvious errors as we get now.
Even teaching how to use the error console would be useful (I imagine most people teaching JavaScript don't know how to use the debugger themselves). At least the error console will usually give a meaningful error message that will point you in the right direction toward trying to fix the problem. Most problems should then be able to be found and fixed. Its only really the more obscure problems that need you to use the debugger to step through the code tracking how the various values change in order to discover where the wrong value is being set that causes the error to occur much later in the code.
True dat. But let's not forget that debugging is an art on its own – maybe even the discipline someone has to master to become a good developer ("everyone can code").
I guess book authors usually think "I'm teaching them to do it right, so why go into debugging – they just gotta not screw up". Unfortunately, it's not that easy. Everyone screws up, even the best of the best. That's why we need to have at least two people who had not been working on the task do a code review before it's merged to a production branch, why we write thousands of tests, why our code goes into E2E testing first and why we're running eight Jenkins.
However, there's something else that "hurts" me: Books for beginners almost never so much as mention (let alone teach) the art of writing clean code. One could argue that it's too much to ask of a beginner, but on the other hand learning this is much harder once all those lazy, dirty habits and patterns have settled in.
Even worse – most books even explicitly teach to write bad code by telling their reader to write a lot of comments etc. But that's another chapter.
Despite all that, people still manage to become great developers. I just think it could just be made easier for them.
Despite all that, people still manage to become great developers. I just think it could just be made easier for them.
Yeah, they could learn it as I did: Without tutorials. Just reference manuals.
I'm convinced that the ability to read reference manuals is what allows a programmer to learn to do the right thing.
Tutorials only teach what the author thinks is WORTH writing about.
Reference manuals lay it all out, often without saying which is the better way.
So you try all the ways and come up with what you think is best. You aren't always right, but if you have any talent at all for programming, you'll be right more often than not.
To illustrate, my introduction to the C language went like this:
Small consulting company. 5 developers plus the boss (who used to program, but didn't much any more). Boss comes in one day and plops a copy of the original K&R C manual on our desks (on 3 of us...other 2 were on other projects) and says "We're going to write a compiler for this language."
None of use had ever coded in C. Only one of us (not me!) had ever worked on a compiler (well, plus the boss, but he'd only worked on a Fortran compiler). So we wrote a C compiler. On a 64KB Zilog Z-80 machine.
A three pass compiler: one of us wrote the preprocessor, one the parser/code tree generator, one the machine code generator and library (me). And it worked. And produced the second fastest code on that architecture at that time. We never got a chance to go back and rework it to make it fastest, but that's another story.
Now *THAT* is how to learn a language. I still understand the "guts" and principles of C better than any other language, with one exception that would take longer to explain. And all because we really had only the reference manual to work from, no tutorials.
__________________
An optimist sees the glass as half full.
A pessimist sees the glass as half empty.
A realist drinks it no matter how much there is.
I did all my first steps with trial & error and reading the manual, too (not something as complex as a compiler, but to be fair – I was 9). I never even so much as touched a book about programming until about 13 years later my current company hired me right after the interview and told me to get familiar with clean code and handed me a book.
I was then put on a project for an international mobile service provider. The software was written in Perl and S-Lang and had to be accessed through a shell (no IDE). And we're talking about 1,000,000+ lines of code here. I had never really used any of those languages or the shell before. Now I know both languages to a fair extent and I love shells, but I never read a book about it – I did use Google a lot, though (which also I think is something people need to learn more; to do research on their own first).
Two weeks ago I was simultaneously put on a second project at the same company. Unlike the first one, this is a project with a lot of stress (28 people in 3 sub-teams) because we got that project to clean up the mess of an Indian outsourcing company. At least this one uses mostly Java, which I also had never used before I worked there. And there it's not just Java – the deployment is a rather complicated process and the system is *huge*.
You grow with your challenges. And you learn by doing things yourself. Which is exactly why I try not to just present the final result to everyone. If it can be googled, I tell them to google. If it can be looked up in the manual, I tell them to look it up in the manual. They may not like it, but on the long run it's the only way for them to not just learn to read code, but to learn to write code.
Yeah. In 1982, we put up our own bulletin board system (BBS) so customers could login and send us messages and get replies. And we thought that was advanced. Hey, we could even handle 1200 baud connections!
__________________
An optimist sees the glass as half full.
A pessimist sees the glass as half empty.
A realist drinks it no matter how much there is.
Before you post, read our: 
