Rubocop should not fail on %{} in arbitrary strings when not using format.
test.rb:1:32: C: Style/FormatStringToken: Prefer annotated tokens (like %<foo>s) over template tokens (like %{foo}).
IMAGEMAGICK_OPTIONS = '-extent %{width}x%{height}'
Create a file called test.rb with the following contents:
IMAGEMAGICK_OPTIONS = '-extent %{width}x%{height}'
Then run rubocop test.rb.
Include the output of rubocop -V. Here's an example:
$ rubocop -V
0.49.0 (using Parser 2.4.0.0, running on ruby 2.3.3 x86_64-linux)
I think this would be much less useful if this was the only behavior or the default behavior. How about a configuration option like OnlyCheckInsideFormat that would reduce the checks to strings inside Kernel#format, String#%, and Kernel#sprintf?
Another false positive case is inside Rails routes.rb file:
get '/guides/:id', to: redirect('/blog/%{id}')
Another false positive case in Rails validation :message.
validates :age, numericality: { message: "%{value} seems wrong" }
ref: http://guides.rubyonrails.org/active_record_validations.html#message
Yet another false positive with Grok patterns like %{FUBAR}.
https://github.com/logstash-plugins/logstash-patterns-core/tree/master/patterns
We can't fix this easily, because of a combination of factors:
%{} syntax is also valid in Ruby format strings.Kernel#format during runtime.So the solution to this is to use one of the existing means of removing false positives. (In order of decreasing granularity):
# rubocop#disable Style/FormatStringtToken. Effective for singular instances.Exclude in .rubocop.yml. Effective for DSL files like Rails routes.
Most helpful comment
Another false positive case is inside Rails
routes.rbfile: