NEWBIE: Ending lines with a semicolon.

[Patrick]

Hi

I am in the process of learning javascript.How come i am being told to
always finish my lines with a semicolon and when i try the 2 following
pieces of code they give the same output which is printing "Hello
world!" to the document.
The second example doesn't have the semicolon, why doesn't the browser
throw an error message?

<SCRIPT TYPE="text/javascript">
document.write("Hello world!"); //Semicolon present
</SCRIPT>


<SCRIPT TYPE="text/javascript">
document.write("Hello world!") //Semicolon missing
</SCRIPT>

Thanks to all

Patrick
(Please answer here or email (e-mail address removed) and remove
NOSPAM.I don't read the address used to post.)

 

[Richard Cornford]

I am in the process of learning javascript.How come i am being
told to always finish my lines with a semicolon and when i try
the 2 following pieces of code they give the same output which
is printing "Hello world!" to the document.
The second example doesn't have the semicolon, why doesn't
the browser throw an error message?

JavaScript performs automatic semicolon insertion (ECMA Script
specification section 7.9). That makes including semicolons in most of
your code optional. However, I, and many others, would recommend using
semicolons wherever they would be inserted by automatic semicolon
insertion (in addition to where they would be required) even if it is
just for 'good style'.

If you examine the ECMA specification you will see that there are a
series of rules for automatic semicolon insertion and that a script
without semicolons will require a considerable extra effort on the part
of the parser working out where the semicolons should go. Explicitly
putting a semicolon in the correct location will save the parser from
having to work out where it should put them.

There are also other languages with a C-like syntax that require
semicolons so getting into the habit of using them will save you time if
you ever have to write in any of those languages.

Richard.

 

[Lasse Reichstein Nielsen]

That's certainly not so in all languages (I don't use those you name);

Not by a long shot, but in all the languages that have inherited their
syntax from C, it is. That includes, to my knowledge;
C, C++, Objective C, C#, Java, AWK, Perl (although Perl has stolen syntax
from quite a number of languages), and PHP.
Javascript is special in that it has stolen most of its syntax from C,
but then added the spurious "semicolon insertion" - probably to accept
scripts written by people who were used to endling their sentences
with a newline. Javascript is *very* accepting.

I agree that using semicolon as a statement terminator is a good idea.
It is like the mantra for network based servers and clients:
"Always be liberal in what you accept, strict in what you emit."
It is a good guideline, and it goes for programming as well. Give the
compiler/interpreter as much information as you can, but build the
compiler/interpreter so that it will do with as little information
as possible.

in Pascal, newline has no more meaning than any other whitespace, never
terminating or separating statements. Pascal is "like" C if one goes as
far as /ad nauseam/; at least, I find the reverse to be the case.

As far as I remember (it has been a while), in Pascal the semicolon is
a statement *separator*, where in C it is a statement *terminator*.

The only difference in practice is that Pascal doesn't require a semicolon
after the final statement of a sequence of semicolon-separated statements.

It's not needed in vbscript either; in fact it's not allowed, the
separator being a full colon. There, newline does terminate a
statement, unless "escaped" with an underline; adding a colon appears
permissible but not customary.

Visual Basic inherits its syntax from more ancient BASICs. They had no
block structure, so the only way to have several statements in a
conditional (the "then"-branch, there was no "else") was to put them
on the same *line* as the rest of the conditional. For that, the colon
was introduced as a statment separator. The newline was a statement
terminator, and Visual Basic has adopted this.

/L

 

[DU]

Lasse Reichstein Nielsen wrote:

[snipped]

It is a good guideline, and it goes for programming as well. Give the
compiler/interpreter as much information as you can, but build the
compiler/interpreter so that it will do with as little information
as possible.

You almost said it but you did not say it so I had to add this. Adding a
semicolon helps speed up the work of the compiler/interpreter so that
page can be rendered faster. Maybe not by much (unless the code is very
long) but it is always a good coding practice.

Semi-colon are also valuable for code readability, code maintainability.
When one read the functions of others, such syntaxical separators for
code instructions help.

DU

 

[Dr John Stockton]

JRS: In article <[email protected]>, seen in

You almost said it but you did not say it so I had to add this. Adding a
semicolon helps speed up the work of the compiler/interpreter so that
page can be rendered faster. Maybe not by much (unless the code is very
long) but it is always a good coding practice.

But the extra code will have, for a Web page, to be transmitted over the
Net, possibly including a modem or radio link; and/or will have to be
read from disc. Those processes will be slower than something done in
RAM by a CPU.

 

[Douglas Crockford]

You almost said it but you did not say it so I had to add this. Adding a

But the extra code will have, for a Web page, to be transmitted over the
Net, possibly including a modem or radio link; and/or will have to be
read from disc. Those processes will be slower than something done in
RAM by a CPU.

The reason to use semicolons is because coding rigor tends to produce
significantly better software. Along with proper commenting and clean
presentation, the code becomes more readable, more maintainable, reducing cost
over its product life.

Avoiding semicolons for the purpose of reducing download time is an extremely
bad tradeoff.

http://www.crockford.com

 

[Evertjan.]

Dr John Stockton wrote on 09 jul 2003 in comp.lang.javascript:

But the extra code will have, for a Web page, to be transmitted over the
Net, possibly including a modem or radio link; and/or will have to be
read from disc. Those processes will be slower than something done in
RAM by a CPU.

Douglas Crockford wrote on 10 jul 2003 in comp.lang.javascript:

The reason to use semicolons is because coding rigor tends to produce
significantly better software. Along with proper commenting and clean
presentation, the code becomes more readable, more maintainable,
reducing cost over its product life.

It seems the divergence of the principles are clear.

Now we need experimental data:

1 timing measurements of actual code execution.

2 timing measurements of download times.

3 double blinded readability tests among a wide cross-section of
experienced and less experienced JavaScript programmers.

4 a long time product life studies of both types of product, prospective
and also double blinded, preferably with placebo code as a third option.

 

[Dr John Stockton]

JRS: In article <[email protected]>, seen in

The reason to use semicolons is because coding rigor tends to produce
significantly better software. Along with proper commenting and clean
presentation, the code becomes more readable, more maintainable, reducing cost
over its product life.

Avoiding semicolons for the purpose of reducing download time is an extremely
bad tradeoff.

Perhaps you did not notice that I was not saying anything about whether
optional semicolons should be included or omitted, but that I was merely
refuting his speed-based argument. Bad arguments should be removed; a
good case can only be harmed by having a deficient component.


If the code is *intended* to be read as code, it should be designed for
legibility, whatever that may mean. But if it is expected that the code
will be downloaded very many times, and the code is not intended to be
read by humans at all, then it should be designed to be compact in
transmission.

Search engine pages, for example, *should* be compact (I've just looked
at one; it's a fine example of compacted, hard to read code (and
apparently non-ideal HTML)).

Pages intended for their source to be read as demonstration material
should be laid out so as to be readily understood.

Otherwise, ordinary pages should be a reasonable compromise.

 

[Douglas Crockford]

You almost said it but you did not say it so I had to add this. Adding a

If the code is *intended* to be read as code, it should be designed for
legibility, whatever that may mean. But if it is expected that the code
will be downloaded very many times, and the code is not intended to be
read by humans at all, then it should be designed to be compact in
transmission.

Wrong. If a program has any on-going value, it should be designed of legibility.
There are free tools (such as www.crockford.com/javascript/jsmin.html) which
will minimize code. I find I get a factor of 2 or 3 reduction. If download
efficiency is vital, then the minified code should be gzip'd as well.

Search engine pages, for example, *should* be compact (I've just looked
at one; it's a fine example of compacted, hard to read code (and
apparently non-ideal HTML)).

Pages intended for their source to be read as demonstration material
should be laid out so as to be readily understood.

Otherwise, ordinary pages should be a reasonable compromise.

No compromise is necessary. Do like the pros do. Always code responsibly.

 

[Dr John Stockton]

JRS: In article <[email protected]>, seen in

Wrong. If a program has any on-going value, it should be designed of legibility.
There are free tools (such as www.crockford.com/javascript/jsmin.html) which
will minimize code. I find I get a factor of 2 or 3 reduction. If download
efficiency is vital, then the minified code should be gzip'd as well.

It would, I think, help if you were to read what you are replying to
with sufficient care to understand its meaning, in full.

I am a poor typist; I write more slowly than I think, and I check before
I post. You appear to be a skilled typist.