Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Use human readable key value pairs for configuration. #47
Instead of the
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
Also once we fix those things we should document it. I had to Google and grep a bit to figure it out =) #41
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.
referenced this issue
Aug 21, 2014
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.
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.
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.