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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
