Descriptive rule names

[HuskyNator]

Is your feature request related to a problem? Please describe.
I struggle with tweaking and reading configuration files due to the large amount of rules & their undescriptive names.
(I'm aware the doc has description, though with the amount of rules, and their existance on different pages, it's still very hard to work with)

Describe the solution you'd like
Give rules descriptive identifiers/names.
For this consider Clang's system.

Describe alternatives you've considered
I've used vsg -co, converted it to yaml (also looked at the predefined jcl style), used a script to remove unused/unfixed entries, and attributes with no real consequence (eg. case_exceptions: [], user_error_message: "", etc) reducing the initial 9660 lines to a config file of 2417 lines. Given the immense amount of different rules, this is however still unworkable.
I've even considered generating comments in my yaml adding the "This rule..." description from the docs.
(A lot of work just to tweak my style)

[HuskyNator]

Sidequestion: How come there are so many rules?
Even Clang doesn't seem to have this many, and that's C++.

[jeremiah-c-leary]

Evening @HuskyNator ,

I struggle with tweaking and reading configuration files due to the large amount of rules & their undescriptive names.

Maybe there could be an alias for each rule?

if_025 :: case_of_if_keyword
architecture_026 :: alignment_of_colons_in_architecture_declarative_region

Sidequestion: How come there are so many rules?
Even Clang doesn't seem to have this many, and that's C++.

I made the decision a long time ago to give the user complete control over the formatting. This turns anything VSG checks into a single rule. Which is how we end up with 700+ rules....and not all the rules have been written yet.

Unfortunately with that much configurability, it makes the initial setup difficult.

I've used vsg -co, converted it to yaml (also looked at the predefined jcl style), used a script to remove unused/unfixed entries, and attributes with no real consequence (eg. case_exceptions: [], user_error_message: "", etc) reducing the initial 9660 lines to a config file of 2417 lines.

I've tried this before and it creates a massive configuration file. I'm wondering if a more efficient method would be to just rely on the default configuration along with using rule groups to set the same configuration over multiple rules and then use targeted rule configurations to fine tune the formatting.

Using the -oc option will just output the default format anyway.

For example, suppose you want all the keywords to be uppercase except for the case keyword. The default format for keywords is lower case. So we use the rule group case::keyword to force every keyword case rule to upper case. Then we add in case_014 to force the case keyword to lower case.

rule:
  group:
     case::keyword:
       case: 'upper'
  case_500:
    case: 'lower'

The side benefit for using rule groups is as new rules are added, and added to the appropriate group, you do not need to add the rule to your configuration.

I want to believe the default formatting matches 80% of what you would want. Hopefully it is just a handful of rules you would actually need to configure.

Regards,

--Jeremy

[HuskyNator]

Maybe there could be an alias for each rule?

Alias would be useful, i would suggest a format like architecture_declarative_region_colon_alignment (no 'of/in' etc, or similar, eg. ArchitectureDeclarativeRegion_ColonAlignment)

Though this wouldn't make any config file containing the other name more readable.

Is there any reason for the use of undescriptive names outside of internal work?
Otherwise I would suggest making descriptive named/aliases default in all user facing scenarios.

I made the decision a long time ago to give the user complete control over the formatting. This turns anything VSG checks into a single rule. Which is how we end up with 700+ rules....and not all the rules have been written yet.

I'm surprised that results in so many rules, and am slightly doubtful anyone would eg. want different keyword to have a different case.
(I'm mostly referring to the fact this is at all possible, the fact the group based approach is possible is a relief, though i'll have to look into the details a bit, i honestly find the documentation a little overwhelming)

Don't mean to be all negative by the way, i'm glad this exists & you're responsive to questions :)

Ps: Good morning, timezones make this a little funny.