I have a project where team style dictates that every ruby file should have an encoding marker.
This is admittedly not something every team wants and wouldn't be a good default check.
Implementing the check was straight forward ( cf7e549 ), however I was surprised at the size of the subsequent commit that wired it into cane ( ba85d41 ).
What do you think about an addition to the rake task that allows teams to load custom checks? Something like:
Cane::RakeTask.new(:cane) do |cane|
new check: ensure all ruby source files have an encoding marker
add encoding check options to CLI
sorry I try to keep my code bases vegan :P
The idea of the run method was to provide a place to default everything to off. Could --no-coding be moved there?
Actually I think I'd want --no-encoding to be the default behaviour, since AFAIK not many teams enforce this style.
Yeah you're right, wiring in new things is kind of insane. Maybe there is a way to combine your use suggestion (which I like) with a way to also set up the right command line params, documentation, etc...
I'm not seriously proposing EncodingCheck for merging upstream, it was mostly to provide code and context for my 'use' suggestion.
The one problem with it is how to support the command line. Is that what you're referring to with "a way to also set up the right command line params, documentation"?
Yeah, I was thinking something like:
# Returns some meta data sufficient to specify command line options and rake task
Then the CLI class can just iterate through all known checks and pull the meta data off them. That way, implementing a new check is all confined to the one class, rather than having to sprinkle things throughout the code base. Maybe it's simpler not even to go the meta data route, instead just call EncodingCheck.translate_cli_options(options). I'd have to play with it.
No obvious next action, closing.
.use method is supported in 2.1.0