Cop idea: string_literal.to_sym

[marcandre]

I was surprised to see that RuboCop doesn't pickup on this in a recent PR:

# bad
'string-literal'.to_sym
# good
:'string-literal'

[koic]

I think this can be suggested to the Ruby style guide :-)

[bbatsov]

I guess this cop should also check for cases like 'string_literal'.to_sym and :'string_literal', as obviously those should have been :string_literal.

[marcandre]

@deepj Why not? keys may start with uppercase, can also be ruby keywords:

h = {
  ABC: 42,
  class: :hello,
  end: 666,
} # => no problem

[dvandersluis]

Exactly what @marcandre said. 'UAE': 'United Arab Emirates' maybe looks like the key will be a string, but it is already a symbol and the quotes are redundant.

{ 'UAE': 'United Arab Emirates' }
=> {:UAE=>"United Arab Emirates"}

[dvandersluis]

The cop doesn't change states['UAE'] to states[:UAE], so you can still access your hash the same as you were previously. The only difference is that the extraneous quotes are removed from the symbol itself (again, your key is not a string, but a symbol, despite the quotes). I don't agree that hashes should not be processed, as I would much rather than UAE: foo than 'UAE': foo.

:'UAE' == :UAE
=> true
:'UAE' == 'UAE'
=> false

[marcandre]

@deepj Maybe you meant to write {'UAE' => 'United Arab Emirates'}? IMO, user facing labels (like 'UAE') should be strings, not symbols.

Let's try and keep HashWithIndifferentAccess out of this, because I can't be partial about this (it's an abomination that was always a bad idea that is no longer needed with strong params)

[deepj]

I apologize, I'm just mixed up several things together.