From 87f86eaf6d3e28ee00caadbb0b52566a06d8319d Mon Sep 17 00:00:00 2001 From: Ilya Kantor Date: Wed, 25 Sep 2019 06:35:52 +0300 Subject: [PATCH] fixes #1369 --- 1-js/99-js-misc/02-eval/article.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/1-js/99-js-misc/02-eval/article.md b/1-js/99-js-misc/02-eval/article.md index 73e8424d..1fdafeee 100644 --- a/1-js/99-js-misc/02-eval/article.md +++ b/1-js/99-js-misc/02-eval/article.md @@ -77,9 +77,9 @@ Right now, there's almost no reason to use `eval`. If someone is using it, there Please note that its ability to access outer variables has side-effects. -Code minifiers (tools used before JS gets to production, to compress it) replace local variables with shorter ones for optimization. That's usually safe, but not if `eval` is used, as it may reference them. So minifiers don't replace all local variables that might be visible from `eval`. That negatively affects code compression ratio. +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 a bad programming practice, as it makes maintaining the code more difficult. +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.