[QA] Ruby Coding Conventions and RuboCop (was: Rubocop style checker)

[Krinkle]

On 20 Nov 2014, at 01:48, S Page <spage at wikimedia.org> wrote:

> Speaking of overzealous rules, The Flow rubocop job was failing on its Gemfile:
> 02:53:31 Gemfile:1:1: C: Missing space after #.
> 02:53:31 #ruby=ruby-2.1.1
> 02:53:31 ^^^^^^^^^^^^^^^^
> 02:53:31 Gemfile:2:1: C: Missing space after #.
> 02:53:31 #ruby-gemset=Flow
> 02:53:31 ^^^^^^^^^^^^^^^^^
> but all our Gemfiles are written this way.
> 
> I stole the fix from CirrusSearch/.rubocop.yml :
> 
> Style/LeadingCommentSpace:
>   Exclude:
>     - Gemfile  # RVM doesn't recognise spaces after the #s
> and now the mwext-Flow-bundle-rubocop CI job passes.
> 
> Is there a way MediaWiki extensions can share common configuration and dev_scripts like this? Maybe extensions/shared, or extensions/Mantle/defaults
> 
> 

This has been suggested in the past for jshint and jscs configuration, which I recommended against at the time. And I think that was for the best.

The downside of centralising configuration affecting tests or style checks is the inability to iterate, improve, extend or change pretty much anything. Whenever a change is made existing code either has to be passing the new version already or various repositories will suddenly find themselves with a failing build for an unrelated commit in their master branch.

That doesn't mean projects should have different configuration. Merely that it's kept in the individual repository. And updated virally as new rules are embraced by our conventions. Also allows project to adopt a style checker with fewer rules at first and integrate stricter rules in smaller chunks.

Among the advantages is also that it allows one to run checks from the command line on your local machine with a generic utility without needing special knowledge (e.g. "my-tool --config .my-config" will consistently work).

Text editor plugins also need to detect the configuration in the working directory of said project. E.g. Sublime Text jshint or jscs plugins wouldn't work otherwise[1].

For jscs we've done a combination of central and local. We centralised the coding style (it's upstream in node-jscsp[2] as preset "wikimedia"). But we don't have any of the downsides of central config because it's still specified by the local config (jscsrc: { "preset": "wikimedia"}), and the version of the node-jscs application is specified in package.json.

For jshint we never used a central config. The file is small enough.

It seems robocop requires quite verbose configuration making it less attractive to maintain in individual repositories. Perhaps we can inherit some kind of base config with only minor local changes, or even upstream our conventions, like I did for jscs.

-- Krinkle

[1] One could set global default to a clone of the Wikimedia style but that still means you'll break master of other repos, and you'd have to keep that clone up to date (instead of coming along with the git clone of said project). And wouldn't scale well when contributing to non-Wikimedia projects.

[2] https://github.com/jscs-dev/node-jscs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/qa/attachments/20141120/6e501299/attachment.html>