To FootSee "About This JavaScript Site" in JavaScript Index and Introduction.
This page is almost entirely based on what I have used myself. Many other tools exist.
Some of this page has been moved from JavaScript General, and is slowly being expanded and rearranged.
Code (both Script and HTML) is easier to read and handle (and to put into Usenet News or into E-mail) if lines are kept below 72 characters in length. It is also easier to read if spaces are included between statements, after commas and semicolons, and around sizeable items; and if divided into logical paragraphs.
Script should be indented, by a couple of spaces per level, to show the logical structure. The Indt button in a copy of JavaScript/HTML/VBS Quick Trials will do a first approximation to logical indenting.
Use local variables in functions whenever possible, and use global variables only when necessary. Anways use var except when needing to declare a global variable within a function.
Name identifiers thoughtfully. Avoid possible clashes with existing and reserved names. Short names suffice for identifiers of limited scope.
Be aware of the distinction between strings and numbers, and remember case-dependency. Use = to assign a value and == to compare for simple equality.
Don't repeat blocks of code with minor differences. Instead, use a function (or a method) with suitable arguments. Modularise the code as much as is practical.
Don't repeat document.getElementById(S) frequently for the same S. Instead, store the result and use that, saving time and space and increasing readability.
For most testing, there is no need to upload to a remote Web server or to run server software on the editing system. Local files can be referenced by using such as C:\PAGES\INDEX.HTM in a browser address bar. Relative links will work on the local machine.
Ideally, one should test on all browsers with all combinations of relevant settings. In practice, one should at least test using, at least, Microsoft Internet Explorer and an established independent browser such as Opera or Firefox. Use the debugging facilities.
Develop code modularly and incrementally; errors are then found quickly and easily. Test modules individually, where possible.
Test as often as is practical; the less that has been changed, the easier it is to locate any errors.
When a bug is suspected, ensure first that the HTML and CSS are valid. Use on-line validators such as W3 HTML validator & W3 CSS validator, and/or download W3's TIDY (which can be used in a checking-only fashion). While online in older Opera, use Ctrl-Alt-V.
Verify your presumptions, about your data and about what JavaScript methods and Object properties actually do and/or look like.
Test with many values, using both good and bad inputs. Where possible, automate tests. Check extreme cases and range end-points.
If an entity seems to be misbehaving, there may be a name clash with some other entity; to test this, change its name to something which cannot reasonably clash.
Always report error messages exactly and in full; and describe carefully the difference between what was intended or expected and what actually occurred.
Sometimes, apparent bugs go away after a reload of the page or the browser, or a re-boot. And make sure that it is using the files you mean it to use.
Debuggers are available for/with various browsers; but often there is no real need to use them.
Debuggers report where the existence of an error is detected, which is not necessarily where the mistake is.
Where code runs but fails to work as expected, it is often helpful to use an Alert box - alert(variable) - to check that variables, especially intermediate results, are indeed taking the expected values, or at least have plausible values.
A local page including HTML as shown can be used for simple JavaScript tests :-
<script type="text/javascript">
function EVAL(F) { F.YYY.value = eval(F.XXX.value) }
</script>
<form><div>
<textarea ID=XXX rows=5 cols=70>2+2</textarea>
<br><input type=button value="Eval" onClick="EVAL(this.form)">
<input type=text ID=YYY size=66 readonly>
</div></form>
The Eval button in a copy of JavaScript/HTML/VBS Quick Trials does substantially that.
See also in the CLJ FAQ.
IE6/7 Tools menu, [Internet Options,] Advanced, deselect "Disable Script Debugging ...", select "Display a notification ...". Also View menu, Script Debugger.
Firefox Tools menu, select Error Console.
Browser settings are accessible with about:config; in particular dom.max_script_run_time.
Opera Tools menu, Advanced, select Error console.
For remote W3 HTML validation, use Ctrl-Alt-V before version 9.50 and Ctrl-Alt-Shift-U from 9.50.
?
FAQ for web developers - Google
"Control the current page" icon > "Developer" > "Debug JavaScript" & "JavaScript console".
As yet, I have used none of these add-ons.
.
Firebug; Web Developer Toolbar.
.
.
.