Intent to support allowed variables in no-underscore-dangle
See original GitHub issueCertain libraries use underscores half privately, half as a requirement. Ember _super is used to reference the parent class.
http://eslint.org/docs/rules/no-underscore-dangle.html
Would there be any interest in supporting a property where the user can specify allowed variables like:
"no-underscore-dangle": [2, { "allowed": ["_super"]}]
Issue Analytics
- State:
- Created 8 years ago
- Comments:15 (13 by maintainers)
Top Results From Across the Web
no-underscore-dangle - ESLint - Pluggable JavaScript Linter
A pluggable and configurable linter tool for identifying and reporting on patterns in JavaScript. Maintain your code quality with ease.
Read more >ESLint Unexpected dangling '_' in '__place' no-underscore ...
My understanding about adding the line before the error code will disable the eslint no-underscore-dangle rule right? – irs102info. May 23, 2017 ...
Read more >Enabled eslint:no-underscore-dangle · ace56c8dc2 - OpenDev
1 .eslintrc. Unescape Escape View File · 10. src/app/services/provider/preference.js. Unescape Escape View File · 4. src/app/util/service/last_location.js.
Read more >Airbnb JavaScript Style Guide()
This is an additional tool to assist in situations where the programmer would be unsure if a variable might ever change. UPPERCASE_VARIABLES are...
Read more >List of available rules - ESLint - Pluggable JavaScript linter
No rules are enabled by default. ... disallow variable or function declarations in nested blocks ... disallow dangling underscores in identifiers.
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
I’ve encountered another use-case for whitelisting, and that is when working with an API that uses fields beginning with underscores. My particular use-case is that I’m working with an API that exposes MongoDB objects, which have the key “_id”, which would be the perfect candidate for whitelisting.
Okay, how about we just simplify here. We’re adding
allow
options to several rules, so we can do the same here. I’ll assume this is a void-your-warranty option so people who use it accept the possibility of it flagging more than expected.