-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
Rule proposal: Boolean variable naming #515
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
Comments
i often use past/future tense stuff for dirty-flag type operations - thoughts? |
@sw-yx Ah yes, forgot about those. They make sense too. |
Seems this could be generalized as sort of like core {
"typescript/typed-id-match": [
"error",
{ "types": [/* ... */], "pattern": "^(is|has|can|did|will)$" },
{ /* ... */ }
]
} |
Should this rule deal with properties? How to deal with property names you cannot control, for example, other people's api? // it probably does not make sense to warn on this
const options = {capture: true, passive: false};
someExternalApi(options); |
Does this rule cover boolean valued functions? |
There's no reason the rule couldn't support all of these things and have options to enable/disable checks. |
Side note: Another possible prefix that may be considered is As an example from the code that induced this comment: function formatArray(data: any[], shouldIgnoreEmpty = false) {
if (data.length === 0 && shouldIgnoreEmpty) {
return ''
} else {
return JSON.stringify(data)
}
} |
I would like to enforce that variables and properties with a boolean use the prefix
is
,has
,can
,did
, andwill
. For example:.visible
→.isVisible
.I often see
.visible
,.open
, etc, in code, and it's not clear whether they are booleans, contain something visible/open, or whether they contain a function that makes something visible or opens something.Fail
Pass
The text was updated successfully, but these errors were encountered: