Prev: Static Class Variables and IE8 Loosely Couple Internet Explorer(LCIE)
Next: IE versions of moz transform
From: Thomas 'PointedEars' Lahn on 11 Jan 2010 03:44 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 11 Jan 2010 11:52 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 11 Jan 2010 12:01 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 11 Jan 2010 12:54 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 11 Jan 2010 14:23
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 |