-
Notifications
You must be signed in to change notification settings - Fork 226
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
Use human readable key value pairs for configuration. #47
Comments
I'm not sure how I feel about not having a numeric ID for rules, but the two arguments I have in favor of them (easier to type and refer to in chat/IM/issues, and no need to change the ID later if the name doesn't make sense any more, such as if I'd named MD007 'multimarkdown_list_indent' before discovering another reason for wanting 4 space indents) aren't that strong. The inspiration for this way of doing things btw is Foodcritic rather than rubocop. It's interesting to see the different choices made between the two. I do really like the idea of having rules be able to take parameters in style files, and it does neatly solve the issue of multiple rules that do essentially the same thing as well as conflicts. |
Refs #47 Rule parameters are settings that can be passed to rules in style files in order to customize their behavior. The settings are provided in style files to enforce a specific style. This commit also changes how ruleset files are evaluated to be more sensible (the block inside the rule is now instance_eval's as part of the Rule object rather than as part of the ruleset object and building up parts of the rule as needed).
Parameters are done and in a branch. They'll be merged once I clean up the rules to use them. However, regarding rule names, I think I'm still going to come down on the side of
Both of these could be solved with aliases, but that sacrifices Ultimately, the tradeoff is reading and recognizing (in style files or other |
I understand the difficulty, and of course the final decision is up to you. I believe:
People will read the files much more than they write them, since every contributor has to read it to know what style to use, but only a few owners will modify the file occasionally. |
Refs #47 This removes duplicates rules (e.g. enforcing specific header styles which can now be configurable), updates the rule documentation and tests appropriately.
The rule parameters option has been merged. As part of this, I updated the style files to not have to exclude the rules that have now been removed. As part of this, I simplified the cirosantilli style file significantly. Let me know if the changes make sense or not. For now I'm closing this issue. Docs on creating style files/rules/parameters I'll add as a separate issue. |
Instead of the
MDXXX
ids, why don't we use human readable key value pairs like:Advantages:
Disadvantage: longer to type. But this is not serious, since projects will write a config file and seldom modify it, and for interactive use according to personal preferences one can just alias it or we can add a global config. Being able to read quickly is more important in this case.
This is what the popular Rubocop does: https://github.com/bbatsov/rubocop/blob/master/config/default.yml.
This could be implemented in either Ruby or YAML: I'd rather have YAML since it allows us not to write
rule
directives all the time and since the config is mostly static, but this is no big deal.Also once we fix those things we should document it. I had to Google and grep a bit to figure it out =) #41
The text was updated successfully, but these errors were encountered: