Transitioning to strict mode

[David Bruant]

Le 18/02/2013 11:10, Claus Reinke a écrit :
>> I'm looking forward to any recommendation you'd have to improve this 
>> guide, specifically about the runtime errors where I said something 
>> about "100% coverage test suite" and I'm not entirely sure about that.
>
> Talking about 100% coverage and "catching all errors" is never a
> good combination - even if you should have found an example of
> where this works, it will be an exception.
There are a couple of things I'm sure of. For instance, direct eval 
aside (eval needs some specific work anyway because its semantics is 
changed a lot), if you have 100% coverage, every instance of setting to 
an undeclared variable will be caught. There is no exception.
But I wonder if that's the case for all runtime errors I listed.
Otherwise, in general, I agree that a test suite with 100% coverage that 
pass doesn't mean that the program is correct. Specifically, in the 
"semantics changes" section, I don't talk about test suites, not even 
with 100% coverage.

Also, in practice, for large projects, 100% coverage is a fantasy. I 
know many software contracts are signed agreeing on 80% coverage, 
because 100% is a lot of work and not even necessary.

What I'm trying to convey in the different sections is the type and 
amount of work that is necessary to be sure the code works when moved to 
strict mode.

> Then there is the issue of pragmatic concerns (can throw at runtime,
> can change semantics on old engines), as expressed in this post
>
> http://scriptogr.am/micmath/post/should-you-use-strict-in-your-production-javascript 
>
>
> To push adoption of strict mode, it might need one or two refinements.
# "we definitely don't want those silent bugs to throw runtime errors to 
our end users on live websites."

I could not agree more. But when I read this sentence, I can't help 
thinking "but why would that ever happen?"
Transitioning to strict mode does *not* mean putting "use strict"; at 
the top of the program and pushing to production. That's the very reason 
I wrote the guide actually. I'll expand the intro to talk about that.
People should run their code locally, test it before pushing to 
production. If people don't test locally before pushing to production, 
transitioning to strict mode should be the least of their concerns.
Also, gradually transitioning down to the function granularity means 
that if an error ever slips into production, it's easy to revert just 
the one function that is not strict-ready yet.


# On older browser not running strict mode

That point is a very valid concern (and I should probably expand the 
guide on this point). I think this point can be summarized by 2 rules:
1) Unless you're a language expert and know what you're doing (you don't 
need that guide anyway), just stay away from things where the semantics 
is different
1.1) eval
1.2) arguments (unless you're in a case where you'd use ...args in ES6)
1.3) odd cases of dynamic "this" (this in non-constructor/method, 
primitive values boxed in objects)
2) Strict mode doesn't make your code throw (either syntactically or 
dynamically)

If those 2 rules are followed, the code will run the same in strict and 
non-strict, no need to worry about it.
Developing new code in strict mode will de facto enforce the second rule 
(assuming people don't want their code to throw as the normal behavior). 
Only discipline (with the help of a static checker watching for the 
this/eval/arguments keywords?) will help to follow the first rule.

Does this sounds false to anyone?


# Concatenation

If the rules of the previous section are followed the code has the exact 
same semantics in strict and non-strict. So if the code is not run in 
the mode it was initially intended for, it won't make any difference.


Thanks for the feedback and the link to the article :-)

David