Ignore symbols ending with ?/! in Style/HashSyntax

[owst]

Perhaps a slightly personal taste, but I think

{ :development? => true }

reads better/is clearer than

{ development?: true }

and therefore Rubocop shouldn't suggest changing the former to the latter. (Similarly for symbols ending in ! e.g. { :raise_on_invalid! => true }.

As an example, the original line I wrote that triggered this was:

expect(Rails).to receive(:env).and_return(double(:production? => true)) 

I'd be interested to know what others think of this one.

---

Before submitting the PR make sure the following are checked:

• Wrote good commit messages.
• Used the same coding conventions as the rest of the project.
• Feature branch is up-to-date with master (if not - rebase it)
• Squashed related commits together.
• Added tests.
• Added an entry to the Changelog if the new code introduces user-observable changes. See changelog entry format.
• All tests are passing.
• The new code doesn't generate RuboCop offenses.
• The PR relates to only one subject with a clear title
  and description in grammatically correct, complete sentences.

[bbatsov]

As this is subjective it should be controlled via some config option.

[owst]

@bbatsov good point - done, and rebased

[bbatsov]

That's a mouthful. :-) Probably we can shorten it a bit.

I'm also not sure we should set it to true by default.

[owst]

haha, yeah definitely, I struggled with it! What about

1. AllowNonAlnumEndingSymbolHashRockets
2. AllowHashRocketsForPunctuationEndingSymbols
3. HashRocketsAllowedWithEndingPunctuation
4. PreferHashRocketsForNonAlnumEndingSymbols

contrasting with the current

• AllowHashRocketsWithSymbolValuesEndingInNonAlnum

Ok, I'll rebase and make it false by default and for now use 4.

[owst]

I'll repaste my reply to @bbatsov since it was hidden by my change:

haha, yeah definitely, I struggled with it! What about

1. AllowNonAlnumEndingSymbolHashRockets
2. AllowHashRocketsForPunctuationEndingSymbols
3. HashRocketsAllowedWithEndingPunctuation
4. PreferHashRocketsForNonAlnumEndingSymbols

contrasting with the current

• AllowHashRocketsWithSymbolValuesEndingInNonAlnum

Ok, I'll rebase and make it false by default and for now use 4.

[bbatsov]

This changelog entry is a bit misleading after the last round of changes.

[owst]

Good point @bbatsov - done