Le 21/02/2013 19:16, Mark S. Miller a écrit :
On Thu, Feb 21, 2013 at 9:12 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 18/02/2013 23:29, Claus Reinke a écrit :
What I'd like to understand is why likely static scoping problems
should lead to a
Le 18/02/2013 23:29, Claus Reinke a écrit :
Out of curiosity, what does your favorite test coverage tool report
for the source below? And what does it report when you comment
out the directive?
:-p Ok, there are exceptions if your code depends on semantic changes
described in the third section
On Thu, Feb 21, 2013 at 9:12 AM, David Bruant bruan...@gmail.com wrote:
Le 18/02/2013 23:29, Claus Reinke a écrit :
What I'd like to understand is why likely static scoping problems
should lead to a runtime error, forcing the dependence on testing.
If they'd lead to compile time errors
You still need more than statement or branch coverage. Otherwise,
we might get 100% coverage while missing edge cases
function raise() {
use strict;
if( Math.random()0.5 || (Math.random()0.5) (variable = 0))
console.log(true);
else
console.log(false);
}
raise();
For the ES5 semantics of the interaction of the global scope and the global
object, how could you make this a static error? What would you statically
test? Would you statically reject the following program, where
someExpression is itself just some valid expression computing a value
(that might be
I think I would have preferred that. But thinking back to the constraints
we imposed on ourselves during the ES5 design process, I doubt we could
have made that choice. Every additional difference between ES3 (or ES5
sloppy) vs ES5 strict had to be argued for. The counter-argument was
migration
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
Le 18 févr. 2013 à 12:29, David Bruant bruan...@gmail.com a écrit :
snip
# On older browser not running strict mode
I was precisely going to write that it is missing an important explicit advice
to produce code that runs both under strict and non-strict mode.
That point is a very valid
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
Le 18/02/2013 16:48, Claus Reinke a écrit :
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
The guide looks really good. Well done!
One thing I learned when trying to convince others to use strict mode
is a tool to help catching the syntax errors. Scanning a large app
code by hand is tedious and error prone. This is one of the reasons I
built an online validator:
Out of curiosity, what does your favorite test coverage tool report
for the source below? And what does it report when you comment
out the directive?
:-p Ok, there are exceptions if your code depends on semantic changes
described in the third section of the article (dynamic
12 matches
Mail list logo
