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
New rule proposal: compact-accessor #12277
New rule proposal: compact-accessor #12277
Comments
I think it's a reasonable rule to add. But would need a different name, compact-accessors doesn't really describe it well. Maybe paired-accessors? |
I like |
They're already paired because they have the same property name; this seems more like |
I don't like
Maybe |
grouped-accessor-pairs? |
This sounds to me like a very good name for this purpose. If its apparent similarity with the existing name accessor-pairs isn't a problem. |
I'll work on this over the weekend, should be ready for review soon. |
Please describe what the rule should do:
If an accessor property has both getter and setter functions, this rule requires their definitions to be one after another in object literals/class definitions.
Optionally, the rule can require their order (get before set, or set before get).
What category of rule is this? (place an "X" next to just one item)
[X] Enforces code style (layout)
Provide 2-3 code examples that this rule will warn about:
Why should this rule be included in ESLint (instead of a plugin)?
While it is allowed, I don't think there is a real use case for non-consecutive definitions of accessor functions for the same property, and it should be a best practice to avoid this feature. Also, the additional option can enforce a consistent style (e.g.,
get
beforeset
).I'm not sure about the rule's name, there could be a better word than
compact
for this.Notes:
accessor-pairs
).no-dupe-keys
andno-dupe-class-members
)Problem: This rule is overlapping with
sort-keys
. But, one might want to enforce this without sorting. Also,sort-keys
doesn't work with classes and doesn't enforce get/set order.Are you willing to submit a pull request to implement this rule?
Yes.
The text was updated successfully, but these errors were encountered: