Le 18 févr. 2013 à 12:29, David Bruant <bruant.d at 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 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

Indeed, eval should only be used by experts; ironically, experts try to avoid eval. :-)

> 1.2) arguments (unless you're in a case where you'd use ...args in ES6)

I would say: Use the "arguments" object only for arguments that are not explicitly named. (And perhaps: use named arguments when possible, although it is more a question of good style than anything else. I guess it is what you meant by "unless you're in a case where you'd use ...args in ES6", but that phrase was a bit confusing for me.)

—Claude

> 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?
> <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.

> 1) stay away from things where the semantics is different
> 1.1) eval

Indeed, eval should only be used by experts; ironically, experts try to avoid eval. :-)

> 1.2) arguments (unless you're in a case where you'd use ...args in ES6)

I would say: Use the "arguments" object only for arguments that are not explicitly named. (And perhaps: use named arguments when possible, although it is more a question of good style than anything else. I guess it is what you meant by "unless you're in a case where you'd use ...args in ES6", but that phrase was a bit confusing for me.)