-
-
Notifications
You must be signed in to change notification settings - Fork 367
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add better-boolean-variable-names
#2446
Conversation
7e59c84
to
7d18b38
Compare
better-boolean-var-names
better-boolean-variable-names
f1bc082
to
bc3134e
Compare
@fregante Found the issue in the codebase, can I fix it directly in this PR, or in separate PR?
|
d5882a4
to
c0b0b0d
Compare
Note that I’m not a maintainer, I just help triage the issues and have lots of opinions. 😅 I’ll leave that to @fisker |
bed94be
to
63f8643
Compare
@fregante OK, can you give me some advice, should I check the function name? eg. function completed(): boolean {}
const isCompleted = completed(); After fix: function isCompleted1(): boolean {}
const isCompleted = isCompleted1(); Applying this rule to functions seems to cause naming problems |
Heh, good point. What should be called In your (corner) case it’s only an issue because you’re “caching” the value. Generally Sindre has preferred appending an underscore when the exact name is unavailable, like By the way I think it would |
<!-- end auto-generated rule header --> | ||
<!-- Do not manually modify this header. Run: `npm run fix:eslint-docs` --> | ||
|
||
When it is clear that an expression is a Boolean value, the variable name should start with `is`/`was`/`has`/`can`/`should` to improve readability. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also: will am are have were got does
|
||
```js | ||
const gotModifyRights = isGotPreviewRights() && isGotDownloadRights(); // ❌ | ||
const isGotModifyRights = isGotPreviewRights() && isGotDownloadRights(); // ✅ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why? I think got is right.
const gotMilk = true
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here is the response from AI:
The word "got" is generally not suitable as a prefix for Boolean variables because it does not conform to the conventions for naming Boolean variables. Boolean variable names typically use verbs or adverbs to clearly express their Boolean value, such as "is," "has," "can," etc.
Using "got" as a prefix may result in variable names that are not sufficiently clear, thereby reducing the readability and maintainability of the code. Therefore, it is recommended to avoid using "got" as a prefix for Boolean variables.
Better choices include the following prefixes:
is
: isUserLoggedInhas
: hasAdminPrivilegescan
: canEditProfileshould
: shouldDisplayNotificationwill
: willSendEmailneeds
: needsPasswordReset
These prefixes can more clearly express the meaning of Boolean variables.
'unicorn/prefer-readable-boolean-variable-names': [ | ||
'error', | ||
{ | ||
prefixes: ['will', 'allows'] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This gives me doubts about this rule. Having to configure your own verbs is a smell to me. allows
should be valid by default… maybe? Or should it be doesAllowDeletion
? What situations are we missing?
I don’t really want1 a rule that bugs you for names that are fine and that might be difficult to get right.
Footnotes
-
meaning: if we add this rule to the recommended and then we get complaints, adding it would be a net loss. ↩
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about we add more prefixes to covering most scenarios? eg.
["is","was","has","had","will","would","can","could","should","shall","does","needs","must","includes","enables","supports"]
These prefixes are treated as valid names, but only a few suggested fixes are provided.
```js | ||
const completed = Boolean('true'); // ❌ | ||
const isCompleted = Boolean('true'); // ✅ | ||
``` | ||
|
||
```js | ||
const completed = new Boolean('true'); // ❌ | ||
const isCompleted = new Boolean('true'); // ✅ | ||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would drop these. No one would code like this.
/** | ||
Capitalize the first letter of a string | ||
|
||
@param {string} str | ||
@returns {string} | ||
*/ | ||
function capitalize(string_) { | ||
return string_.charAt(0).toUpperCase() + string_.slice(1); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should be un utils.
Also:
/** | |
Capitalize the first letter of a string | |
@param {string} str | |
@returns {string} | |
*/ | |
function capitalize(string_) { | |
return string_.charAt(0).toUpperCase() + string_.slice(1); | |
} | |
/** | |
Capitalize the first letter of a string. | |
@param {string} string | |
@returns {string} | |
*/ | |
function capitalize(string) { | |
return string.charAt(0).toUpperCase() + string.slice(1); | |
} |
rules/utils/is-boolean.js
Outdated
@param {import('estree').Expression} node | ||
@param {number} [deep] - The current recursion depth. Users do not need to pass this parameter. | ||
*/ | ||
function isBooleanExpression(context, node, deep = 0) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
function isBooleanExpression(context, node, deep = 0) { | |
function isBooleanExpression(context, node, depth = 0) { |
rules/utils/rename-variable.js
Outdated
/** | ||
Replace the string between start and end with replacement. | ||
|
||
@param {string} str |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does not match actual parameter.
rules/utils/rename-variable.js
Outdated
function isExportedVariable(identifier) { | ||
return ( | ||
identifier | ||
&& identifier.parent?.type === 'VariableDeclarator' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use tab-indentation.
rules/utils/rename-variable.js
Outdated
* ```js | ||
* export const foo = 1 | ||
* ``` | ||
* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't prefix comment lines with *
@@ -0,0 +1,162 @@ | |||
# Prefer readable Boolean variable names |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
# Prefer readable Boolean variable names | |
# Prefer readable boolean variable names |
<!-- end auto-generated rule header --> | ||
<!-- Do not manually modify this header. Run: `npm run fix:eslint-docs` --> | ||
|
||
When it is clear that an expression is a Boolean value, the variable name should start with `is`/`was`/`has`/`can`/`should` to improve readability. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When it is clear that an expression is a Boolean value, the variable name should start with `is`/`was`/`has`/`can`/`should` to improve readability. | |
Boolean variable names should start with `is`/`was`/`has`/`can`/`should` for clarity and readability. |
|
||
```js | ||
{ | ||
'unicorn/prefer-readable-boolean-variable-names': [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tab-indentation.
63f8643
to
d412470
Compare
rules/utils/is-boolean.js
Outdated
@param {number} [depth] - The current recursion depth. Users do not need to pass this parameter. | ||
@returns {boolean} | ||
*/ | ||
function isBooleanExpression(context, node, depth = 0) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know there is a method isBooleanNode
, but it is not comprehensive enough, and it cannot track the type of Identifier.
eslint-plugin-unicorn/rules/utils/boolean.js
Lines 32 to 37 in 461b01c
function isBooleanNode(node) { | |
if ( | |
isLogicNot(node) | |
|| isLogicNotArgument(node) | |
|| isBooleanCall(node) | |
|| isBooleanCallArgument(node) |
So, I need more advice, should I use the same method.
a40eb9c
to
2077601
Compare
Close #2441
Perhaps
prefer-readable-boolean-variable-names
is a better name?