Automatic semicolon insertion ...
in [JavaScript]
|
Prev: Static Class Variables and IE8 Loosely Couple Internet Explorer(LCIE)
Next: IE versions of moz transform
From: Hans-Georg Michna on 11 Jan 2010 16:59 On Sun, 10 Jan 2010 20:47:57 -0800 (PST), Michael Haufe ("TNO") wrote: >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. Here's another vote for writing semicolons. Experience shows that relying on automatic semicolon insertion causes errors that are sometimes difficult to find. By the way, I have had a recent case where semicolon insertion was over-eager in Internet Explorer 8. I had split a lengthy return statement into several lines, and IE8 inserted a semicolon where I had not intended to be one. That is, of course, the opposite problem. It just shows that automatic semicolon insertion is not very well thought out. Hans-Georg
From: "Michael Haufe ("TNO")" on 11 Jan 2010 20:07 On Jan 11, 1:23 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > It could be easily tested. Do tell. > You have been arguing that omitting semicolons is not a bad practice. > Now you are arguing that it is. Make up your mind. Wrong assumption. My position is that the lack of use of semicolons does not equate some generic claim of "bad practice". Since IME the potential ambiguities are rare and don't warrant having to change programming style in all places. If you want to use them everywhere just to feel warm and fuzzy inside, more power to you. > I think you are confusing this with Strict warnings caused by conditional > returns. I'm referring to spider monkey's strict warnings as an example. It has nothing to do with a conditional return.
From: "Michael Haufe ("TNO")" on 11 Jan 2010 20:14 On Jan 11, 3:59 pm, Hans-Georg Michna <hans- georgNoEmailPle...(a)michna.com> wrote: > By the way, I have had a recent case where semicolon insertion > was over-eager in Internet Explorer 8. I had split a lengthy > return statement into several lines, and IE8 inserted a > semicolon where I had not intended to be one. I would consider an overly long return statement a code smell anyway. Its simple enough to wrap the statement with parentheses or break the line(s) along operators instead of names.
From: Thomas 'PointedEars' Lahn on 12 Jan 2010 06:15 Michael Haufe ("TNO") wrote: > Thomas 'PointedEars' Lahn wrote: >> It could be easily tested. > > Do tell. Set up a loop using eval() (so as to have a new /Program/ on each call) and count the milliseconds it takes with and without explicitly inserted semicolon in the `eval' string argument. >> You have been arguing that omitting semicolons is not a bad practice. >> Now you are arguing that it is. Make up your mind. > > Wrong assumption. My position is that the lack of use of semicolons > does not equate some generic claim of "bad practice". Since IME the > potential ambiguities are rare and don't warrant having to change > programming style in all places. And I do not agree, partially because you have yet to make a convincing case. > If you want to use them everywhere just to feel warm and fuzzy inside, > more power to you. Straw man. >> I think you are confusing this with Strict warnings caused by >> conditional returns. > > I'm referring to spider monkey's strict warnings as an example. It has > nothing to do with a conditional return. Yes, especially there it has. The warning is "Function does not always return a value." which is only displayed with conditional returns. The example you have posted does not, in general, cause a Strict warning to be displayed if Strict warnings are enabled. PointedEars -- var bugRiddenCrashPronePieceOfJunk = ( navigator.userAgent.indexOf('MSIE 5') != -1 && navigator.userAgent.indexOf('Mac') != -1 ) // Plone, register_function.js:16
From: "Michael Haufe ("TNO")" on 12 Jan 2010 12:41
On Jan 12, 5:15 am, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > Michael Haufe ("TNO") wrote: > > Thomas 'PointedEars' Lahn wrote: > >> It could be easily tested. > > > Do tell. > > Set up a loop using eval() (so as to have a new /Program/ on each call) and > count the milliseconds it takes with and without explicitly inserted > semicolon in the `eval' string argument. Do you have a test case for your numbers? Looking for a normalized newline token is just as easy as looking for ";" in a tokenizer and/or a TDOP parser for example, so I'm withholding judgment. > And I do not agree, partially because you have yet to make a convincing > case. Nor have I heard a convincing case for always using them and everywhere just to prevent a possible ambiguity in places that seem to me to be very easy to recognize. At this point we're just running circles on this topic. > Yes, especially there it has. The warning is "Function does not always > return a value." which is only displayed with conditional returns. The > example you have posted does not, in general, cause a Strict warning to be > displayed if Strict warnings are enabled. Here's the code: function foo(){ return true } Here's the resulting warning (using Fx 3.6 RC1 + Strict Warnings): "useless expression" |