11

I always code in strict mode hoping to be shielded(or at least forcibly told to change my code) from problems with the Javascript language like using deprecated methods or misinterpretable syntax.

However I hit this problem today and I was wondering whether there was any way to disable semicolon insertion in the browser or otherwise have similar-to-strict-mode 'compile'-time errors?

JS[H/L]int doesn't happen to be able to pick up where JS interpreters would insert semicolons and flag them for us to mitigate would it?

EDIT

JShint and JSLint both error if a new line is present before a semicolon is found after a the return keyword. However, I don't know about the other caveats regarding automatic insertion and whether they are each detected too.
Regardless, if an answer actually solves the 'disabling' part, that would be more relevant.

Community
  • 1
  • 1
Hashbrown
  • 12,091
  • 8
  • 72
  • 95

2 Answers2

1

The expression after return keyword MUST ALWAYS start on the same line that the keyword is, this is not interpreter related, it's defined by the ECMAScript standard, it's a bad part of the language but if you respect the rules of writing the JS code described by Douglas Crockford then you'll not encounter this again.

From "JavaScript: The Good Parts" by Douglas Crockford (Appendix A.3 Awful Parts):

JavaScript has a mechanism that tries to correct faulty programs by automatically inserting semicolons. Do not depend on this. It can mask more serious errors.

It sometimes inserts semicolons in places where they are not welcome. Consider the consequences of semicolon insertion on the return statement. If a return statement returns a value, that value expression must begin on the same line as the return:

return
{
    status: true
};

This appears to return an object containing a status member. Unfortunately, semicolon insertion turns it into a statement that returns undefined. There is no warning that semicolon insertion caused the misinterpretation of the program. The problem can be avoided if the { is placed at the end of the previous line and not at the beginning of the next line:

return {
    status: true
};

Also see the code conventions for JavaScript by Douglas Crockford: http://javascript.crockford.com/code.html

Community
  • 1
  • 1
micnic
  • 10,915
  • 5
  • 44
  • 55
  • although this is true, I don't doubt that there are other caveats. Regardless, at the very least it may be interesting just to see where JS interpreters are inserting stuff in our code (if there is an automated solution. As opposed to learning the specific cases where it would) – Hashbrown Aug 28 '13 at 08:03
  • 1
    @Hashbrown, please see my edited answer, I don't know about any automated solution, but if you'll use Java like code style this problem is solved. – micnic Aug 28 '13 at 08:21
  • 3
    I know what is happening, I want to stop it. I'm not 'relying' on the insertion, it's hindering me. And again, the point on the question is not regarding the `return` issue, that is what just flagged my attention, there would be other things it would insert to as well that I'd like rooted out – Hashbrown Aug 28 '13 at 11:15
  • 8
    It looks like disabling may be asking for too much, but I would be very happy to simply detect insertion, i.e., get a report from the compiler telling me what it did. I am too stupid to write code that always follows ECMAScript standards or Crockford - I have even been known to make spellling mistakes and syntax poorly, sometimes on the same day. For that kind of stupidity, I need an automated process, not another human telling me to shape up. – DaveWalley Jan 09 '14 at 16:17
  • 3
    this isn't really an answer to the question, just a "you're doing it wrong" which isn't helpful – thepaulpage Aug 09 '17 at 15:39
1

Just thought I'd help anyone who comes across this question.
I've started using Google's Closure Comiler to minify JS for a project and it gave me a few handy warnings.

   $> java -jar google_closure_compiler.jar  --language_in=ECMASCRIPT5_STRICT --js_output_file 'min.js' 'file1.js' 'file2.js'
   file1.js:152: WARNING - unreachable code
               getSomething(function() { return this.doThingo(''); });
               ^

   file2.js:203: WARNING - Suspicious code. The result of the 'add' operator is not being used.
               ' to ' + (typeof obj);
               ^

   0 error(s), 2 warning(s)

The offending code blocks were as follows (the comments describe what the code was missing that the compiler alerted me to):

file1.js:150

    return generateSomeObject(bunch, of, arguments)
        //the period before the function call was missing
        getSomething(function() { return this.doThingo(''); });
}

file2.js:201

if (someCondition)
    //trailing plus was missing from this line
    throw 'Could not set ' + last + ' of ' + (typeof root)
        ' to ' + (typeof obj);
return old;

I don't know whether it will recognise all mistakes that the browser tidies up (so I probably won't mark this as an answer), but it does a lot more than YUI's minifier was doing for me (which was ignoring all of these cases).
Also, compared to YUI, the compiler is able to take in multiple file inputs and so can give me line numbers per file for errors, and doesn't error on/redeact the debugger keyword).
Hopefully it'll help you too.

Hashbrown
  • 12,091
  • 8
  • 72
  • 95