Fix spelling of offence (s/b offense)

[jhx]

No description provided.

[bbatsov]

That's a difference in American English. Everyone else writes "offence".

[joseph-ravenwolfe]

One neutral point of reference for this is that the Ruby language itself is implemented in American English. One example being that initialize in Ruby is not spelled with an 's', but rather a 'z'. The difference can also be seen in Ruby's use of String#center over 'centre', and capitalize over 'capitalise'.

[bbatsov]

@josephjaber True. I'll think about changing this, but it's pretty hard for someone like me to write offense :-)

On a more serious note - there are packages that depend on RuboCop and are likely manipulating offences - renaming the class will be problematic for some of them.

[bbatsov]

@jonas054 @yujinakayama What do you think?

[yujinakayama]

I'm on the fence about this. If we'll change it, we need to consider backward compatibilities:

• Methods: alias_method :do_something_with_offence, :do_something_with_offense
  • Though we need to check how many methods will be affected and whether we should support aliasing private APIs.
• Class: class Offense; end; Offence = Offense
  • I guess almost all third party programs (mainly custom formatters) manipulate Offence instances but don't access the constant Offence.
• Formatter: Allow both key offenses and offences for OffenceCountFormatter

[jonas054]

We must admit that we made a mistake with the spelling. It should have been offense from the start. However, it seems like changing it now is a lot of trouble. I say we keep it as it is.

[yujinakayama]

Probably the timing of release of RuboCop 1.0 would be a good chance to handle this.

[jhx]

My thought is misspellings make software look unprofessional and we should correct it before Rubocop makes a major version release. Per semantic versioning (semver.org), it's expected to have some incompatibilities when the major version is incremented.

Can we handle the API change similar to how chefspec handles deprecations? They provide a deprecations.rb module to provide functionality until you can clean up your code.

require 'chefspec/deprecations'

[bbatsov]

@jhx @jonas054 This was a deliberate choice on my part as I dislike the American spelling of many words... I'm not saying it was good decision, but I'm saying this wasn't a misspelling. :-)

I'll keep the discussion open for now (to see if other members of the RuboCop community will voice their opinions) and we'll make the final decision down the road.

[dblock]

I vote to deprecate the non American spelling FWIW. English is my third language, but I found the spelling odd. I wouldn't worry about backwards compat too much, it will be very clear to someone upgrading if things are broken and this isn't a gem used in production runtimes.

[jdickey]

I think that should be a team/project decision.

Whether we're operating in an English or American language environment, most of us no doubt have tools such as editors that hook into system spelling-checkers and so on. Having the "other" language's spelling constantly flagged with red squiggly lines is a distraction too likely to train us to ignore such errors in non-code tools. And nobody, on either side of the divide, can seriously expect the other to swap languages used for email, word processing, etc…

Our preferred approach to date has been to attempt to identify such potential issues, and try to come up with domain-meaningful names with invariant spelling between the two languages. Where that's not practical, e.g. with a property named favouriteColour, we'll do one of two things:

1. If it's in something for internal use, or not expected to be published as open source, we'll use local conventions. I that case, favouriteColour would remain as it is, to avoid confusion for other local developers we may take on later; or
2. If it's in something expected (or considered) to be published, we'll alias the other language's usage (FavoriteColor, in this example) to the "correct" declaration. (Even as I type this, a red squiggly appears under the Americanism.)

Reduce distractions where possible, and in all other cases, accommodate. There are somewhat more native English speakers than American speakers in the world, even if the developer community has historically been imbalanced. It will not likely always be so.

[bbatsov]

In light of all arguments I've decided to go with offense. I've renamed everything without adding any API fallbacks for now. The changes required by projects depending on RuboCop should be trivial, anyways.

[yujinakayama]

I think I'll check some major external tools that are using RuboCop's public API, and send pull requests.

[yujinakayama]

It seems no change is required in almost tools.

• rubocop-emacs: Using emacs formatter. No change is required.
• vim-rubocop: Using emacs formatter.
• flycheck: Using emacs formatter.
• syntastic: Using emacs formatter.
• sublime_rubocop: Using progress formatter. No change is required. (Though parsing progress format is discouraged.)
• guard-rubocop: Using json formatter. Already fixed.
• rubocop-checkstyle_formatter: A custom formatter. Worked without change.

[bbatsov]

@yujinakayama Good news! Thanks for taking the time to check this.