Books
in black and white
Main menu
Home About us Share a book
Books
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics
Ads

Javascript for dummies 4th edition - Veer E.V

Veer E.V Javascript for dummies 4th edition - Wiley publishing , 2004. - 387 p.
ISBN: 0-7645-7659-3
Download (direct link): javascriptfordummies2005.pdf
Previous << 1 .. 85 86 87 88 89 90 < 91 > 92 93 94 95 96 97 .. 118 >> Next

http://devedge.netscape.com/central/javascript
• Microsoft’s JavaScript-compatible JScript language reference:
http://msdn.microsoft.com/scripting/jscript/default.htm
Chapter 16: Ten (Or So) Most Common JavaScript Mistakes 271
Include browser-detection code.
Chapter 3 shows you how to create a script that detects a visitor’s browser on-the-fly and behaves differently based on different browser capabilities.
^ Always test your scripts in multiple browsers before publishing them.
Documentation can be wrong, and browser-detection code can malfunction. So before you actually post your JavaScript-enabled pages to your Web server (thereby exposing them for all the world to see), always test them yourself in as many browsers as possible.
Although the America Online browser has a fairly large market share, it’s often overlooked by JavaScript developers. You can download your own free copy of this browser from http://free.aol.com.
Rather than downloading and installing multiple browsers, you can take advantage of an online service, such as NetMechanic, to help you spot cross-browser bugs at this site:
www.netmechanic.com/cobrands/zdnet/browsercheck
272 Part V: The Part of Tens
Chapter 17
Ten (Or So) Tips for Debugging Your Scripts
In This Chapter
^ Comparing code to design specifications ^ Tracking down bugs with alerts ^ Getting help from online resources ^ Watching the code in process ^ Breaking up functions ^ Turning user errors into useful information ^ Getting familiar with JavaScript debugging tools
■ n Chapter 16, you see some of the most common mistakes (or bugs) that JavaScript programmers tend to make. This chapter expands on that theme by showing you the quickest, most direct ways to pinpoint and correct any bugs that you happen to introduce into your code. Many language compilers and interpreters come complete with tools for debugging. Unfortunately, few debugging tools exist for JavaScript just yet. I introduce you to those tools later in this chapter — along with some great advice for debugging your JavaScript code as quickly and easily as possible.
Debugging is sort of like washing dishes. Neither chore is exactly a ton of fun, but both are necessary, and you always feel better when they’re finished. Debugging doesn’t have to be a dreaded chore, though. You might find that, with a little help (like the tips presented in this chapter) and a little practice, the job gets easier and easier.
274 Part V: The Part of Tens
JavaScript Reads Your Code, Not Your Mind!
Strangely enough, the first step in successful bug extermination involves determining whether you’ve actually encountered one. If your JavaScript script doesn’t behave the way that you expect it to, you could be dealing with a bug. However, your script might be working as designed, and the problem is in your understanding of how the script is supposed to work.
In the old days, programmers created flowcharts — pages and pages of little symbols and lines that described how they wanted their programs to behave at runtime. Flowcharts have fallen out of favor — not because they were a bad idea but because they were nearly as time-intensive to create as the programs themselves.
These days, most programmers find it helpful to write pseudocode as part of the design process. Then, during testing, these programmers have something to refer to — a touchstone, as it were, to help them clarify whether a potential bug lies in their JavaScript code or in their programming logic.
Pseudocode is a shorthand combination of JavaScript and the programmer’s natural language. Because this tool is designed to be as easy and natural for programmers as possible, no hard-and-fast rules define precisely how to write pseudocode.
Say, for example, that your goal is to calculate the total price (including sales tax, if any) for international orders placed through your Web site. Here’s an example of what your pseudocode might look like:
1. The user presses the Submit button.
2. If it’s a U.S. order, calculate the tax (look up the tax rate based on
myForm.state) and store the calculated tax in totalTax
else {What to do if non-U.S. orders?!}
3. Multiply the number of widgets (myForm.numWidgets) ordered by the price (myForm.price). . . .
As useful as writing pseudocode is to helping you clarify the requirements of a Web page, it’s absolutely indispensable when it comes to tracking down bugs in your logic after you finish implementing your Web page.
Chapter 17: Ten (Or So) Tips for Debugging Your Scripts 275
Don't keep your comments to yourself
Getting into the habit of commenting on your JavaScript code as you write it can be a great help when it comes time to debug that code. (You might be surprised at how much you can forget between the time you create a script and the time when your code misbehaves, which can be weeks or even months down the line!)
If you create pseudocode to help you plan and design your scripts, try using that pseudocode as the basis for your JavaScript comments. Doing so helps the future you (or someone else who has to debug your script) understand precisely what the code is trying to accomplish.
Previous << 1 .. 85 86 87 88 89 90 < 91 > 92 93 94 95 96 97 .. 118 >> Next