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 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 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 parameters.
Don't repeat document.getElemenyById(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.
Develop code modularly and incrementally; errors are then found quickly and easily.
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 Opera, use Ctrl-Alt-V.
Debuggers are available for/with various browsers; but often there is no real need to use them.
Where code fails, it is often helpful to use an Alert box - alert(variable) - to check that variables are indeed taking the expected values.
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.
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 JavaScript/HTML/VBS Quick Trials does substantially that.
IE6 Tools menu, Advanced, deselect "Disable Script Debugging ...", select "Display a notification ...".
Firefox Tools menu, select Error Console.
Opera Tools menu, Advanced, select Error console.
Use Ctrl-Alt-V for remote W3 HTML validation.
?
As yet, I have used none of these.
.
Firebug; Web Developer Toolbar.
.
.