Remove duplicated ESLint reference. Close #84

README.md

@@ -402,11 +402,11 @@ All statements above will return false if used with `===`
 
 <br/><br/>
 
-## ![✔] 4.2 Detect code issues with ESLint + specific Node plugin rules
+## ![✔] 4.2 Detect code issues with a linter
 
-**TL;DR:** ESLint is the de-facto standard for checking code style, not only to identify nitty-gritty spacing issues but also to detect serious code anti-patterns like developers throwing errors without classification. On top of ESLint standard rules that cover vanilla JS only, add Node-specific plugins like [eslint-plugin-node](https://www.npmjs.com/package/eslint-plugin-node), [eslint-plugin-mocha](https://www.npmjs.com/package/eslint-plugin-mocha) and [eslint-plugin-node-security](https://www.npmjs.com/package/eslint-plugin-security)
+**TL;DR:** Use a code linter to check basic quality and detect anti-patterns early. Run it before any test and add it as a pre-commit git-hook to minimize the time needed to review and correct any issue. Also check [Section 3](https://github.com/i0natan/nodebestpractices#3-code-style-practices) on Code Style Practices
 
-**Otherwise:** Many faulty Node.JS code patterns might escape under the radar. For example, developers might require(variableAsPath) files with a variable given as path which allows attackers to execute any JS script. Node.JS linters can detect such patterns and complain early
+**Otherwise:** You may let pass some anti-pattern and possible vulnerable code to your production environment. 
 
 
 <br/><br/>
@@ -716,4 +716,4 @@ This repository is being kept up to date thanks to the help from the community.
 🌻 [Vedran Karačić](https://github.com/vkaracic), 
 🌻 [lallenlowe](https://github.com/lallenlowe), 
 🌻 [Nathan Wells](https://github.com/nwwells), 
-🌻 [Paulo Vítor S Reis](https://github.com/paulovitin), 
+🌻 [Paulo Vítor S Reis](https://github.com/paulovitin),