![]() |
Last document.write not displaying text statement
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> |
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.
|
Probably because you have errors in the code.
Just for starters: Code:
document.write("Last name: " + this.lName + BR);Code:
function Account(type, num, lName, fName, bal) {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). |
You also seem to have used a word processor for creating this code.
Look carefully here: Code:
this.firstName = fName;If you have been using a word processor, past time to stop. It *will* lead you into more trouble. Use a code editor of some kind. |
Nice catch with the ligature there. Finding a bug like that can be a real pain in the ***.
|
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. |
Quote:
|
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. |
Quote:
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. |
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. |
Now if we had just had Google in 1978. <grin/>
|
You could've written it!
Well, except that the internet didn't exist yet. :D |
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!
|
| All times are GMT +1. The time now is 09:15 PM. |
Powered by vBulletin®
Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.