I just made the correction in my new reader, thanks for the tip.
But did you make the right correction? Having adjusted the line wrapping
to what looks like about 100 characters the text in your post is now
coming out in a form that makes it difficult to read because my
newsreader is set to display in a window with only about enough
horizontal space for 80 odd characters. The result is that it re-wraps
your 100 character text lines so every other line is half as long as its
predecessor.
You could get around that by manually wrapping you text in the 60-80
character range and leaving the long lines for the code. Personally I do
the reverse and leave my newsreader wrapping posts at a relatively
narrow 72 characters but manually break my JavaScript so that I post
functional code (does not need to be unwrapped) within those margins.
Do you mean just hitting enter after June or
what is the proper way to break a line?
JavaScript (ECMA Script) is extremely tolerant of white space (including
line breaks) within its source code. There are in fact only a couple of
places where white space characters are not allowed. For example, a line
break may not be placed between a the - return - keyword and any
expression that is to be returned. The ECMA Script specification
describes this with the production for return:-
return [no-lineTerminator here] Expression (opt) ;
(the "opt" is subscript and refers to the semicolon being optional.)
So a statement such as:-
if((a)&&(a<b)&&(a>=c))d=a;
-may also be written as:-
if ( (a) && (a < b) && (a >= c) ) d = a;
-or-
if((a)&&
(a < b)&&
(a >= c)
)d = a;
-or-
if(
(a) && (a < b)&&(a >= c)
) d = a;
-or-
if (
(
a
) &&
(
a < b
) &&
(
a >= c
)
)
d = a;
-or (if you really wanted to write obscure code):-
if
(
(
a
)
&&
(
a
<
b
)
&&
(
a
c
)
)
d
=
a
;
-and the JavaScript interpreter would be able to sort it out and
determine that it was the same statement as the original.
One of the main reasons that JavaScript is so tolerant of white space is
to allow the structure of the source code (how the code is laid out in a
text editor) to convey additional meaning (usually related to structure
of the program) and maximise clarity for human readers. If you look at
the various examples above it should be clear that some are easier to
understand than others. The last, for example, would be close to
impossible to interpret and that would make source code structured in
that way extremely difficult to debug. The first (without any spaces) is
also not particularly clear.
The main source code structuring consideration that adds clarity is
block indenting (usually with tabs). A block is defined with curly
brackets - { - and - } - and represents a block statement (which may
contain zero or more other statements). It is normal to indent the
statements within a block by one tab character, though that tab is
usually set to 4 or less spaces width as the normal default 8 spaces
width is a bit too deep for most practical uses).
There are various common styles of block indenting, of which I prefer to
leave the opening - { - at the end of the control statement (on the same
line) and list the block contents as one statement per line, indented by
an additional tab with the closing - } - on a new line of its own one
tab out from the block contents so that it lines up vertically with the
start of the control statement. EG:-
function doSomething(oArea){
var nArea = oArea.nWidth * oArea.nHeitht;
var result = true;
if(!nArea){
removeRegion(oArea);
result = false;
}else if(nWidth < nHeight){
result = oArea.reShape(nArea);
}
return result;
}
The same function may also be commonly formatted:-
function doSomething(oArea)
{
var nArea = oArea.nWidth * oArea.nHeitht;
var result = true;
if(!nArea)
{
removeRegion(oArea);
result = false;
}
else if(nWidth < nHeight)
{
result = oArea.reShape(nArea);
}
return result;
}
-or-
function doSomething(oArea)
{
var nArea = oArea.nWidth * oArea.nHeitht;
var result = true;
if(!nArea)
{
removeRegion(oArea);
result = false;
}
else if(nWidth < nHeight)
{
result = oArea.reShape(nArea);
}
return result;
}
Though I very much dislike the latter.
In all cases the indenting servers to make the structure of the function
apparent in the structure of the source code. The important thing is to
pick an indenting style and stick to it (unless you find yourself
working for a company which has chosen its own house style for
indenting, in which case there are better arguments for all internal
code to be indented in that style).
Note that this is only relevant to development code, code downloaded
with a web page can be devoid of all the extra unnecessary white space
characters (and there are lots of programs that will automatically strip
them out) but during development (and when posting to news groups) code
should be as easy as possible to follow and understand.
However, Indenting with tab characters is not without it's problems when
posting to news groups, as at least some news software likes to strip
tabs out (or collapse them to single spaces). I always try to avoid that
problem by using the "convert tabs to spaces" feature on my text editor
prior to posting code. Also, It is usually best to read newsgroups on
which code if frequently posted in a fixed width font (else all the work
put in to extending clarity by formatting the source code becomes a bit
pointless).
The next consideration is how to handle long lines in news group posts.
Sometimes I find that just re-setting the width of the tab character to
2 (or 3) spaces will reduce the width of the code to within my required
72 character margins (prior to using the "convert tabs to spaces") and
no other adjustments are needed.
However, if a statement must be broken across several lines it should
not be indented at the same level as it's own start and it should not be
indented at the same level as its block contents (if any), but if block
indenting is at 4 space intervals then indenting a broken line at 1 to 3
characters should server to make it clear that it is indenting separate
from the general block structure of the code. EG:-
function otherWindowTest(obj){
if((document.compatMode)&&
(document.compatMode == 'CSS1Compat')&&
(document.documentElement)){ //<< broken statement
return document.documentElement;
}else if(document.body){
return document.body;
}else{
return obj;
}
};
Another alternative for formatting statements broken across lines is to
disregard the indenting on the left and line the code that belongs to
the broken statement up on the right hand side. EG:-
this.position = function(){
var sDsize;
if(--delay <= 0){
step();
if(((z+=fv) >= planeDepth)||
((dy+dm) > windowCenterY)||
((dx+dm) > windowCenterX)||
(v < 0)){ //right aligned broken statement
this.reset();
step();
}
div.top = (sy+(py*dy)-dm)+posMod;
div.left = (sx+(px*dx)-dm)+posMod;
divClip.height = (sDsize = (dm<<2)+posMod);
divClip.width = sDsize;
}
next.position();
};
To date I am yet to write a JavaScript that could not be formatted
reasonably to fit within the 72 character margins that I normally use
and both express it's block structure in it's format and be capable of
being cut directly form my posts and executed unaltered in a browser.
Richard.
(Your final code re-formatted to less than 72 character line lengths as
an example):-
function events() {
var today = new Date();
// [ ... ] == Array literal notation.
var dayarray = ["Sun","Mon","Tue","Wed","Thu","Fri","Sat"];
var montharray = [
"Jan","Feb","Mar",
"Apr","May","Jun",
"Jul","Aug","Sep",
"Oct","Nov","Dec"
];
document.write('<table border bgcolor="ffffff" cellpadding',
'="3"><tr><td><center><b>DATE</b><\/center>',
'<\/td><td><center><b>OPPONENT<\/b><\/center>',
'<\/td><\/tr>');
var ct = 1;
var hg = [
["2004/03/09 23:59:59","DES MOINES"],
["2004/03/19 23:59:59","LINCOLN"]
];
for (var i = (hg.length-1);i>=0;i--) {
var event = hg
[1];
var date = new Date(hg[0]);
var year = 1900 + date.getYear()%1900 // < AD 3800
var cdate=dayarray[date.getDay()] +
", " +
montharray[date.getMonth()] +
" " +
date.getDate() +
" " +
year+" ";
if (ct <= 5) {
if (today.getTime() <= date.getTime()) {
ct++;
document.write('<tr><td valign=top>' +
cdate +
'<\/td><td> ' +
event +
'<\/td><\/tr>');
}
}
}
document.write('<\/table>');
}