• You can write arbitrary Ruby code as a plugin • We rarely develop the plugin for project speciﬁc rules • It needs a lot of work (high cost), but the plugin is only for a few people (low return) What if we can make the development cost low enough?
http://github.com/soutaro/querly $ querly check lib/main.rb:1:14 Exception You probably should use StandardError lib/main.rb:12:5 File.open("foo.txt") Use block to read/write file spec/main_spec.rb:6:4 pp 1+2 Delete debug print
are project-speciﬁc ones • The patterns you can deﬁne in Querly is restricted to encourage adding new rules • Patterns you cannot write means it is out of the scope of Querly Rule ﬂexibility Deﬁnition difficulty Querly RuboCop
to explain what the rule is fore more correctly • Examples are executable spec rules: - id: com.sample.non_null_migration pattern: "_.string(:symbol:, !null: _)" message: < Do you really want a nullable column? justification: - When you want a nullable column examples: - before: "t.string(:name)" after: "t.string(:name, null: true)"
review at one time is not too big, false detections are ok • Hook pull requests! • Run Querly analysis when you open new pull request • Ignore issues from the code which is not changed in the pull request
comment, we always think if we can write a Querly rule for that • When we are deprecating an API: octokit() • We can ship new API without completely replacing old one • When hidden requirements are uncovered: validates(:symbol:, ..., uniqueness: _, ...) • Better than asking your teammates to read all of the docs
covers project speciﬁc rules • Rules are deﬁned by patterns • Used in my team to DRY up code review suggestions • Design decisions • Limited ﬂexibility for ease of deﬁnitions • Handle false detections by extra layer to ﬁlter them