Categorise rules and allow analysing only specific categories + new rule for changing ruleset to rulesets
#278
Comments
|
I'm thinking about how would we configure the categories that are applied? A new option alongside e.g. |
|
I like your idea but the I would change the |
Can you give an example?
Or an example for this one?
I don't think we've used a Wiki since we introduced the |
[
{elvis, [
{config, [
#{
dirs => ["src"],
filter => "*.erl",
rulesets => [this_ruleset, the_other_ruleset, that_ruleset, …]
}
]}
]}
].
[
{elvis, [
{rulesets,
#{my_custom_ruleset =>
[{elvis_style, no_tabs}, this_ruleset, the_other_ruleset, that_ruleset, …]}
},
{config, [
#{
dirs => ["src"],
filter => "*.erl",
ruleset => my_custom_ruleset
}
]}
]}
].
I guess they had… since we approved/merged the PR after asking them to update the wiki ;) |
|
Ok, so if there's only one ruleset we coerce it In that case "categories" becomes simply "rulesets" and it'd play nice with the expected results summary I propose (good idea). Now we just have to find the proper rulesets :) I'll try to name them and put the rules in them... As for the custom rulesets, I don't know if it'd apply. The goal is for us to be able to add more meta info. to the rules, and custom rulesets, as implemented, as already very flexible in that regard. |
|
What d'ya think about this? Category "Style and formatting"Rules:
Category "Modularity and structure"Rules:
Category "Readability"Rules:
Category "Refactoring"Rules:
Category "Error-prone patterns"Rules:
Category "Consistency"Rules:
Category "Naming"Rules:
Category "Anti-patterns"Rules:
Category "Type and interface enforcement"Rules:
Category "Project"Rules:
|
And we add a rule to
Exactly.
I don't understand this one, sorry. But I guess we can discuss adding |
|
Regarding the list… comments inline
I would add
I think
I think that
In my mind,
To me,
If we have a "Consistency" category… then that rule about using the word
I like this one. I wouldn't mind having
As I said before, I would be inclined to merge this category with the "Error-prone" one above.
👌🏻
👌🏻 |
|
I did not check if you included all rules in the list above. In any case, we should also consider all the tickets for new rules that we have… and maybe think about the category each one should belong to. |
Later, maybe?
I did; I'll update the list with your comments and potentially comment some more. |
This. |
Enabled by default? If so, that's a breaking change, but I wouldn't mind, since we're kinda using SemVer already (and we have a migration helper). |
|
The updated list is (categories "Readability" and "Anti-patterns" are gone)... Category "Style and formatting"Rules:
Category "Modularity and structure"Rules:
Category "Refactoring"Rules:
Category "Error-prone patterns"Rules:
Category "Consistency"Rules:
Category "Naming"Rules:
Category "Type and interface enforcement"Rules:
Category "Project"Rules:
|
paulo-ferraz-oliveira
changed the title
ruleset to rulesets
|
That new rule |
I ❤️ it!!The final list is perfect! |
Is your feature request related to a problem? Please describe
I'd like to be able to split
elvis' rules into categories, have that information output in the result logs and be able to run only a specific set of categories.e.g. refactor opportunity, good practice, readability
Describe the solution you'd like
No clear solution as of yet, but first we need to list the rules against the categories.
The text was updated successfully, but these errors were encountered: