diff --git a/1-js/99-js-misc/02-eval/article.md b/1-js/99-js-misc/02-eval/article.md
@@ -1,25 +1,25 @@
-# Eval: run a code string

-The built-in `eval` function allows to execute a string of code.

-The syntax is:

```js
let result = eval(code);
```

-For example:

```js run
let code = 'alert("Hello")';
eval(code); // Hello
```

-A string of code may be long, contain line breaks, function declarations, variables and so on.

-The result of `eval` is the result of the last statement.

-For example:
```js run
let value = eval('1+1');
alert(value); // 2
@@ -30,7 +30,7 @@ let value = eval('let i = 0; ++i');
alert(value); // 1
```

-The eval'ed code is executed in the current lexical environment, so it can see outer variables:

```js run no-beautify
let a = 1;
@@ -46,15 +46,15 @@ function f() {
f();
```

-It can change outer variables as well:

```js untrusted refresh run
let x = 5;
eval("x = 10");
alert(x); // 10, value modified
```

-In strict mode, `eval` has its own lexical environment. So functions and variables, declared inside eval, are not visible outside:

```js untrusted refresh run
// reminder: 'use strict' is enabled in runnable examples by default
@@ -65,27 +65,27 @@ alert(typeof x); // undefined (no such variable)
// function f is also not visible
```

-Without `use strict`, `eval` doesn't have its own lexical environment, so we would see `x` and `f` outside.

-## Using "eval"

-In modern programming `eval` is used very sparingly. It's often said that "eval is evil".

-The reason is simple: long, long time ago JavaScript was a much weaker language, many things could only be done with `eval`. But that time passed a decade ago.

-Right now, there's almost no reason to use `eval`. If someone is using it, there's a good chance they can replace it with a modern language construct or a [JavaScript Module](info:modules).

-Please note that its ability to access outer variables has side-effects.

-Code minifiers (tools used before JS gets to production, to compress it) rename local variables into shorter ones (like `a`, `b` etc) to make the code smaller. That's usually safe, but not if `eval` is used, as local variables may be accessed from eval'ed code string. So minifiers don't do that renaming for all variables potentially visible from `eval`. That negatively affects code compression ratio.

-Using outer local variables inside `eval` is also considered a bad programming practice, as it makes maintaining the code more difficult.

-There are two ways how to be totally safe from such problems.

-**If eval'ed code doesn't use outer variables, please call `eval` as `window.eval(...)`:**
-
-This way the code is executed in the global scope:

```js untrusted refresh run
let x = 1;
@@ -95,20 +95,20 @@ let x = 1;
}
```

-**If eval'ed code needs local variables, change `eval` to `new Function` and pass them as arguments:**

```js run
let f = new Function('a', 'alert(a)');

f(5); // 5
```

-The `new Function` construct is explained in the chapter <info:new-function>. It creates a function from a string, also in the global scope. So it can't see local variables. But it's so much clearer to pass them explicitly as arguments, like in the example above.

-## Summary

-A call to `eval(code)` runs the string of code and returns the result of the last statement.
-- Rarely used in modern JavaScript, as there's usually no need.
-- Can access outer local variables. That's considered bad practice.
-- Instead, to `eval` the code in the global scope, use `window.eval(code)`.
-- Or, if your code needs some data from the outer scope, use `new Function` and pass it as arguments.