From: Thomas 'PointedEars' Lahn on
Michael Haufe ("TNO") wrote:

> Nik Coughlin wrote:
>> Michael Haufe ("TNO") wrote:
>> > Nik Coughlin wrote:
>> >> Forget it, always use semicolons. Omitting them is bad practice.
>> > According to whom?
>>
>> According to common sense. They introduce needless ambiguity. What does
>> this do?
>>
>> return
>> {
>> automaticSemicolons: "bad idea"
>> };
>
> The specification clearly defines this as dead code (ES5 7.9.1).

No, the Specification clearly defines this as code that exits the
local execution context with returning the `undefined' value.

> Understanding the specification and the language eliminates such
> ignorance.

Yet it stands to reason that where there is a semicolon in the right place
in the source code it does not need to be automatically inserted,
potentially increasing the overall efficiency of the code, and avoids (if
not entirely prevents) ambiguities, mostly not in favor of the compiler,
but the programmer. However, a good scripting IDE would flag the "dead
code".

Not that your example would make for a convincing case for omitting
semicolons to begin with as, for reasons of Pretty Printing, Object
initializers should already be written differently than Block statements.
So I question whether the ignorance you mention is really in the place that
you assume it to be.


PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
From: "Michael Haufe ("TNO")" on
On Jan 10, 11:14 pm, Nik Coughlin <nrkn....(a)gmail.com> wrote:

> It's an example of code that has a different effect to what most
> programmers would expect, not an incitement to write such code. There
> are plenty of other such cases.

This type of code will throw a strict warning , so I don't think its a
proper example.

> Regardless of one's knowledge of the language and the specification,
> anything that is as counter intuitive as the unintended effects of
> semicolon insertion is best avoided.

If you feel more comfortable using it, far be it from me that I would
tell you otherwise, but I don't buy the argument of it being some
holiest of holy "best practice"

> Additionally there are exceptions where semicolons are not optional.

Which IME is quite a rare occurrence.

> So you introduce all of this ambiguity and add the necessity to remember
> special rules, just so that you can save typing one character per line.
> Sometimes. It's a bloody horrible idea.

You're making a conclusion based on an exaggeration. There are
countless web pages missing semi-colons and they still work without
ambiguity.
From: "Michael Haufe ("TNO")" on
On Jan 11, 2:44 am, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
wrote:

> No, the Specification clearly defines this as code that exits the
> local execution context with returning the `undefined' value.

You're correct. It's more appropriate for me to say that it infers
that such code is treated as a useless statement.

> > Understanding the specification and the language eliminates such
> > ignorance.

> Yet it stands to reason that where there is a semicolon in the right place
> in the source code it does not need to be automatically inserted,
> potentially increasing the overall efficiency of the code...

That's an implementation detail, and would be a hard claim to test I
think.

> ... and avoids (if not entirely prevents) ambiguities, mostly not in favor of the compiler,
> but the programmer.  

An excellent point, but real world code does not seem to reflect this
view, since such a large number of scripts lack the "proper" use.

> However, a good scripting IDE would flag the "dead code".

It also throws a strict warning in some implementations.
From: Richard Cornford on
On Jan 11, 4:47 am, Michael Haufe ("TNO") wrote:
> On Jan 10, 7:43 pm, JR wrote:
>> On Jan 10, 9:23 pm, Michael Haufe ("TNO") wrote:
>>> On Jan 10, 4:47 pm, Nik Coughlin wrote:
>
>>>> Forget it, always use semicolons. Omitting them is bad practice.
>
>>> According to whom?
>
>> Douglas Crockford has written about it:
>> http://www.crockford.com/javascript/survey.html
>
>> "Semicolon Insertion
>> One of the mistakes in the language is semicolon insertion. This
>> is a technique for making semicolons optional as statement
>> terminators. It is reasonable for IDEs and shell programs to do
>> semicolon insertion. It is not reasonable for the language
>> definition to require compilers to do it. Use semicolons."
<snip>
> You want to use them? More power to you, but I for one don't
> prescribe to Crockford's opinion on this subject. I would argue
> it is more reasonable to put the burden on the compiler than
> the programmer.

The example in the OP is a case where the inability to automatically
insert a semicolon impacts the meaning of the code. Inverse examples
exist where automatic semicolon insertion has a similarly unwanted
effects. Fore example, suppose:-

if(!x)
{
x = 1;
}

- were typoed into:-

iff(!x)
{
x = 1;
}

- then the line terminator between the closing parenthesis and the
opening brace allows for a semicolon to be inserted, and the resulting
code is then syntactically correct. There is now a runtime error
waiting to be triggered when (or if) execution encounters this code.

If there were no automatic semicolon insertion then the typoed version
becomes a syntax error and so would be reported at the point of
parsing the code.

Of course a blanket 'best practice' of telling the programmer that
they should always write their own semicolons will not address cases
where no semicolon was ever wanted (much as it does not address the
possibility of accidentally omitting one (say, falling to press the
semicolon key hard enough) and ending up with a function call were
none was expected as in the OP example), but the fact that automatic
semicolon insertion can turn what could have been an easily (and
automatically) spotted syntax error into a (possibly very obscure)
runtime error lends weight to the assertion that the whole idea was a
mistake. It is better for the compiler to be taking what it receives
literal (and complaining if it does not like it) and for the burden to
be on the programmer to write what they mean, given that the complier
is not in a position to deduce the programmer's intended meaning from
the text it is presented with.

Richard.
From: Thomas 'PointedEars' Lahn on
Michael Haufe ("TNO") wrote:

> Thomas 'PointedEars' Lahn wrote:
>> > Understanding the specification and the language eliminates such
>> > ignorance.
>> Yet it stands to reason that where there is a semicolon in the right
>> place in the source code it does not need to be automatically inserted,
>> potentially increasing the overall efficiency of the code...
>
> That's an implementation detail, and would be a hard claim to test I
> think.

It could be easily tested.

>> ... and avoids (if not entirely prevents) ambiguities, mostly not in
>> favor of the compiler, but the programmer.
>
> An excellent point, but real world code does not seem to reflect this
> view, since such a large number of scripts lack the "proper" use.

You have been arguing that omitting semicolons is not a bad practice.
Now you are arguing that it is. Make up your mind.

>> However, a good scripting IDE would flag the "dead code".
>
> It also throws a strict warning in some implementations.

I think you are confusing this with Strict warnings caused by conditional
returns.


PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16