Beginning JavaScript with DOM Scripting and Ajax, 2nd Edition

CHapTer 3 ■ FroM DHTML To DoM SCripTing
Code Layout
First and foremost, code is there to be converted by the interpreter to make a computer do something—or at least this
is a very common myth. The interpreter will swallow the code without a hiccup when the code is valid—however,
the real challenge for producing really good code is that a human will be able to edit, debug, amend, or extend it
without spending hours trying to figure out what you wanted to achieve. Logical, succinct variable and function names
are the first step to make it easier for the maintainer—the next step is proper code layout.
■ Note if you are really bored, go to any coder forum and drop an absolute like “Spaces are better than tabs” or
“every curly brace should get a new line.” You are very likely to get hundreds of posts that point out the pros and cons
of what you claimed. Code layout is a hotly discussed topic. The following examples work nicely for me and seem to be
a quite common way of laying out code. it might be a good idea to check whether there are any contradictory standards
to follow before joining a multi developer team on a project and using the ones mentioned here.
Simply check the following code examples; you might not understand now what they do. (They present a small
function that opens every link that has a CSS class of small popup in a new window and add a message that this is
what will happen). However, just consider which one would be easier to debug and change.
Here they are without indentation:
function addPopUpLink(){
var popupClass='smallpopup';
var popupMessage= '(opens in new window)';
var pop,t;
var as=document.getElementsByTagName('a');
for(var i=0;i