Fix rubocop violations

[charlesjohnson]

• Add a .rubocop.yml to the generator cookbook_files
• Updated app generator to write out rubocop.yml
• Updated cookbook generator to write out rubocop.yml
• Added .rubocop.yml to chefignore
• Fixed rubocop violation in Berksfile
• Fixed rubocop violations in metadata.rb
• Fixed rubocop violations in serverspec default_spec.rb
• Fixed rubocop violations in chefspec default_spec.rb

[charlesjohnson]

Some notes:

• The rubocop.yml is based mostly on the .rubocop.yml published by @someara in the chef-cookbooks/mysql and chef-cookbooks/httpd repos, as those seem to be a de facto standard. I added some stuff to get rid of specious violations in metadata.rb around column alignment and some warnings whose corrections would have made the spec tests less readable, but it's mostly the same. The important thing is to get something out there for people to argue about, we can always iterate.
• 'chef generate cookbook' and 'chef generate app' now make rubocop-clean output with this file.
• I'm on the fence about adding the .rubocop.yml to 'chef generate repo.' Seems like a good idea but also room for unintended consequences, so I didn't. Thoughts?

[lamont-granquist]

StringLiterals should also be turned off, as per rubocop/rubocop#520 even bbatsov recognizes that the community is split on this one, and I positively can't stand it.

Generally rubocop is going to be quite a bit of a bikeshed which is why we left it off initially I think

[lamont-granquist]

See #37 for other discussion.

Between the cops where Rubocop doesn't do the right thing (e.g. 'rescue Exception` followed by immediately re-raising the exception is perfectly valid), tries to engineer a brand new community standard where there isn't one (e.g. replacing 'raise' with 'fatal' because someone bbatsov is impressed with suggested it at one point), tries to engineer a standard that i'd argue goes against the community (e.g. suppressing trailing commas on multiline hashes and arrays), and just picks one side by default in a bikeshed war (StringLiterals), I don't think there's any way to arrive a decent consensus.

[charlesjohnson]

THE QUICKENING BEGINS. See, I like StringLiterals. Clearly we must fight with knives.

Persona bias right up front: I see lots of value in Rubocop, it definitely helped me level up a lot of my code as a sysadmin-turned-Chef.

In the absence of a defined style guide / standard for Ruby in general and Chef in particular, I agree that de facto solutions such as Rubocop can be aggravatingly fluid, misguided, and flat-out wrong. But also, right now CHEF has a small army of customer-facing engineers/consultants engaging with the community and preaching Rubocop as good practice for Chef code. We also ship the tool as part of the ChefDK. By having no .rubocop.yml in the generator, we're saying that Every. Single. Cop. is valid for Chef cookbooks, which I think we CAN agree is pretty much madness. If we're shipping Rubocop then some set of almost-sane defaults seems a reasonable thing to ship with it.

If people don't like those defaults, they can configure their own. That's why .rubocop.yml exists, along with custom generator support. Also, what we ship here can evolve over time.

Yes, there's probably no way to reach a happy consensus on this, but I think we can find a everyone-grumbles-about-it consensus. However, if we can't come to consensus, then perhaps another PR ripping out Rubocop completely is in order? What I don't want to see is that CHEF continues shipping it and preaching it, while also leaving it with insane defaults.

[lamont-granquist]

Yeah, but are we preaching it? @sethvargo invented preaching about it in the chef community then backed way off after he felt they jumped the shark quite a bit. I also think its got some utility, but it needs to be put onto a fairly tight leash.

FWIW my standard .rubocop.yml looks like this:

ClassLength:
  Enabled: false
CommentAnnotation:
  Enabled: false
Documentation:
  Enabled: false
DoubleNegation:
  Enabled: false
Encoding:
  Enabled: false
FormatString:
  Enabled: false
IfUnlessModifier:
  Enabled: false
LineLength:
  Enabled: false
MethodLength:
  Enabled: false
PercentLiteralDelimiters:
  Enabled: false
SignalException:
  Enabled: false
SingleSpaceBeforeFirstArg:
  Enabled: false
SpaceInsideBrackets:
  Enabled: false
SpaceInsideParens:
  Enabled: false
StringLiterals:
  Enabled: false
TrailingComma:
  EnforcedStyleForMultiline: comma

SpaceInsideBrackets and SpaceInsideParens are also things that drive me nuts. I like to leave a little whitespace to let expressions visually 'breathe' a bit to add some clarity.

SingleSpaceBeforeFirstArg needs to be off for providers/ and recipes/ as well, or else you can't justify you arguments together, which I definitely like to do:

file do
  owner "root"
  group "root"
  mode  "0644"
end

[sethvargo]

Having literally gone 360° on this, I agree with @lamont-granquist on this one. Let me elaborate...

It really boils down to this - at the end of the day Chef != Ruby. Sure, Chef is written in Ruby, but recipes are a highly specialized DSL that does not fit in the guise of standard Ruby programming.

At the end of the day, style is a team decision. As a single individual writing cookbooks, style matters not. Once I share the responsibility of that cookbook maintenance with my team, however, a style begins to emerge. This is highly variant based on the individuals involved, and it is also an evolving process - you don't just BOOM, style. The argument that open source cookbooks should follow a common style is also lost on me. Maintainers should totally decide the style that works best for their repos, but that's not Chef Software's decision to enforce tbh. If Sean wants to use Rubocop, that's great, but that doesn't mean every user should, or that every user should have the same set of rules either. Each project is unique and has its own style which is up to the maintainer(s) to enforce with whatever tools they please.

From a purely economic perspective, the cost-benefit-analysis does not pay off. "Errors" (if you can call them that) are confusing to new users. You are only increasing the already huge learning curve for Chef. You must learn x, y, z, and now w before you can write package "apache2". From Chef Software's perspective, go look at foodcritic. It's become a giant bikeshed because people are passionate about something that really doesn't matter. They waste valuable time and energy arguing over something that is ultimate insignificant, like using symbol keys in mashed. (You can argue that symbols are faster than strings because of GC, but when your CCR takes 30s, do you really notice the additional 0.0000052s incurred for the Ruby VM to throw some strings on the stack?) I think there are much bigger fish to fry (and much bigger engineering wins) than pointing sharp sticks at each other. To put it another way, I think @danielsdeleo, @lamont-granquist, et al's time is better spent making Chef(DK) a better experience than arguing with a vocal community member on single versus double quotes.

Introducing Rubocop to the Chef community is one of my biggest regrets. If I could go back and change it, I would. But I can't. So here we are. I would heavily discourage this addition.

[sethvargo]

So, TL;DR the solution to the problem is not to add a .rubocop.yml and expose the foundation of the largest bike shed construction of all time, but rather stop preaching about Rubocop. Sometimes the simpler solution is better, and I firmly believe this is one of those cases.

[lamont-granquist]

Yep, I'd prefer to see PRs that refactored code into tighter objects with better specs, which is 100x the payoff towards a better codebase than style fixes.

[charlesjohnson]

If consensus is that the best way to make ChefDK awesome is to rip Rubocop out completely, I'm down. As I said, what I don't want to see is that CHEF continues shipping Rubocop and preaching it, while also leaving it with an insane set defaults.

[lamont-granquist]

Thing is that right now we just ship it, we don't wire it up in any way as far as I know, so its just there if you want to use it. If you start using it, I think you inherently start needing to buy into maintaining your own .rubocop.yml file and that needs to go into your own custom generators.

[kramvan1]

I still believe rubocop is a helpful tool to allow teams to maintain some style consistency. But I also agree that the style should reflect our Chef environment more so then a pure Ruby one. I think it would be great to have ChefDK continue to include rubocop AND include an example rules file that focuses on the basic style most cookbooks already have (like the one above).

[charlesjohnson]

This is an illuminating thread, with lots of good discussion.

I feel pretty strongly that "do nothing" is a bad option. "Here is a tool BUT DON'T YOU DARE USE IT" is a lousy thing to say to a user. "Here is a tool but the output is bonkers unless you write your own customized config dotfile in yaml, and locating the docs for that config file and determining its location in your project is left as an exercise to the user" is an even more lousy thing to say.

ChefDK's purpose is to give the user tools to be awesome at writing Chef code. By bundling Rubocop we're tacitly blessing it as a tool for that purpose. By bundling it without a .rubocop.yml in the generator, we're tacitly blessing Rubocop with AllCops enabled on every file. Which I think we all agree makes it useless out of the box.

So if we leave it in, then I think we have to have the bikeshed, and at least dictate some starting point for a community standard. And if we rip it out, then we don't have the bikeshed, but also we don't have the tool, and maybe that's okay? But I'd like to hear from more people on that one.

As to how widely it's used: CHEF currently teaches Rubocop as part of the Intermediate Chef training, so if we make this change then that will need revision as well.

[someara]

Mark me down as a +1 for shipping rubocop + a curated .rubocop.yml.

The whole point of the DK is to put people in The Right Path (tm).

Having a tool that can do automated lint correction (rubocop -a) is a
very powerful thing, and we should ship it.

[ "having"
, 'eleventy',
:billiion.to_s,
]

%w( syntactically valid ways) %w{to do a thing} is actually hostile to new
users, and anything that encourages standardization is a huge win in my
book.

The default rubocop rules are annoying, but there is a LOT of good stuff in
there.

Shipping a Chef Software Recommended starting rubocop.yml, with commented
links to the rubocop docs is a good way to not throw the baby out with the
bath water.

-s

On Tue, Feb 17, 2015 at 1:32 PM, Charles Johnson notifications@github.com
wrote:

This is an illuminating thread, with lots of good discussion.

I feel pretty strongly that "do nothing" is a bad option. "Here is a tool
BUT DON'T YOU DARE USE IT" is a lousy thing to say to a user. "Here is a
tool but the output is bonkers useless unless you write your own customized
config dotfile in yaml, and locating the docs for that config file and
determining its location in your project is left as an exercise to the
user" is an even more lousy thing to say.

ChefDK's purpose is to give the user tools to be awesome at writing Chef
code. By bundling Rubocop we're tacitly blessing it as a tool for that
purpose. By bundling it without a .rubocop.yml in the generator, we're
tacitly blessing Rubocop with AllCops enabled on every file. Which I think
we all agree makes it useless out of the box.

So if we leave it in, then I think we have to have the bikeshed, and at
least dictate some starting point for a community standard. And if we rip
it out, then we don't have the bikeshed, but also we don't have the tool,
and maybe that's okay? But I'd like to hear from more people on that one.

As to how widely it's used: CHEF currently teaches Rubocop as part of the
Intermediate Chef training, so if we make this change then that will need
revision as well.

—
Reply to this email directly or view it on GitHub
#320 (comment).

[lamont-granquist]

I just don't see how shipping rubocop without any wiring at all is tacitly blessing all cops.

Also WRT this statement: "Here is a tool but the output is bonkers unless you write your own customized config dotfile in yaml, and locating the docs for that config file and determining its location in your project is left as an exercise to the user"

That is exactly what you've got now when you gem install rubocop. That feels like a statement of fact about the way the world is. They didn't write rubocop to be minimally invasive and generally correct out of the box and instead wrote it with a ton of opinions so to make it usable you have to turn them off. Yet some people may like all the cops being turned on as well (I know there's arguments on twitter suggesting exactly that).

[lamont-granquist]

And when it comes to %w{} vs %w() I've been doing it the former for years and don't buy bbatsov's argument that I need to change (I don't think dan does either).

[sethvargo]

I fail to see how pasting around a 50+ line YAML file to every cookbook (and then changing that YAML file each time rubocop decides to include another rule) is a productive use of anyone's time.

The simple fact is that it really doesn't matter. We should be encouraging users to pick a style of their choosing. You have to write recipes this way seems to go against the original founding principles of Chef.

[charlesjohnson]

CHEF promises paying customers contractual support for all things in the ChefDK package. Thus all of the things that are included in the ChefDK package are blessed by sheer virtue of that inclusion. In addition, nothing has been explicitly wired together in the ChefDK, so that would imply that none of the package contents are blessed at all.

Providing a standard is not the same as _telling people they _have* to do things a certain way.* CHEF advocated for single repository development for years before Berks came along and blew that up. Standards provide guidance, and a point to argue with if that guidance is not positive. Standards can evolve.

Plus there's already a standard for Rubocop defined in the ChefDK, and that standard is "use Rubocop with AllCops," which I think is confusing, harmful, and should not remain. Thus this thread.

(I'm intentionally ignoring syntax/style arguments for a moment. I'd rather focus on "should we include Rubocop at all" as the question.)

[sethvargo]

should we include Rubocop at all?

No. My vote is a very hard "no".

[someara]

This less about the "philosophy of freedom" than it is about "the reality
of chaos".

It really boils down to two questions:

Do we lose anything by shipping a .rubocop.yml in the default generator?
Do we win anything by shipping a .rubocop.yml in the default generator?

Losses:

• Having to curate the default rules over time, dealing with ridiculous
  rules as they appear.
• A loss of "git blame" value in the face of "rubocop -a" commits

Wins:

• Automated(!!) standardization of style across codebases. (tabs/spaces,
  whitespace, strings, symbols)
• Less explaining to do around Ruby syntax TMTOWTDI
• Easy stepping stone to cookbook testing (Foodcritic provides this too)

My view on this is colored by spending large amounts of time dealing with
other people's code AND dealing with new users.

-s

On Tue, Feb 17, 2015 at 2:35 PM, Seth Vargo notifications@github.com
wrote:

I fail to see how pasting around a 50+ line YAML file to every cookbook
(and then changing that YAML file each time rubocop decides to include
another rule) is a productive use of anyone's time.

The simple fact is that it really doesn't matter. We should be
encouraging users to pick a style of their choosing. You have to write
recipes this way seems to go against the original founding principles of
Chef.

—
Reply to this email directly or view it on GitHub
#320 (comment).

[danielsdeleo]

Personally, I'd be quite receptive to an outcome where we could say "some teams find enforcement of style rules to be a useful process to improve code readability within/across working groups. If you'd like to opt-in, Here's a set of sane defaults you can easily tailor to your needs. And we have a sane way of upgrading this component without causing a bunch of test failures or maintenance hassles." I don't think we can do this with rubocop because:

1. Making style stuff opt-in not really a problem, but isn't in this PR as written.
2. There is no consensus on what a sane set of defaults is for rubocop.
3. The generator cookbooks aren't very pluggable at the moment, you have to fork the whole thing to customize rubocop rules (which is what you'd need to do to add rubocop if we didn't provide it out of the box).
4. Rubocop is a compatibility disaster. Each new version adds a bunch of checks that make your existing code fail the style checks. The only way to deal with this is to strictly version rubocop with the codebase you run it against or have some way that your team manages the global version you use everywhere. The only reasonable way to version it with your code is to use bundler. For the second option, we could say "you get the version in ChefDK and we don't consider upgrading it a compatibility breakage." But that's a pretty frustrating user experience. People are going to want "no rubocop updates before Christmas because the team is too busy" or whatever.
5. Problem (4) is exacerbated by the fact that Rubocop is configured on a per-project basis, so if you upgrade the version in use globally, you potentially have to modify N config files.

[lamont-granquist]

I still fail to understand how shipping rubocop installed but without any default wiring becomes a 'standard'.

However, given that, then I'm in agreement with dan and seth that it simply needs to get dropped and users need to chef gem install or bundle install the exact version they desire.

[someara]

+1 on dropping if we're not going to ship sane defaults

-s

On Tue, Feb 17, 2015 at 4:16 PM, Lamont Granquist notifications@github.com
wrote:

I still fail to understand how shipping rubocop installed but without any
default wiring becomes a 'standard'.

However, given that, then I'm in agreement with dan and seth that it
simply needs to get dropped and users need to chef gem install or bundle
install the exact version they desire.

—
Reply to this email directly or view it on GitHub
#320 (comment).

[someara]

Is there another ruby-level linter that allows for rule whitelisting vs
Rubocop's rule blacklisting model?

On Tue, Feb 17, 2015 at 5:02 PM, Sean OMeara someara@chef.io wrote:

+1 on dropping if we're not going to ship sane defaults

-s

On Tue, Feb 17, 2015 at 4:16 PM, Lamont Granquist <
notifications@github.com> wrote:

I still fail to understand how shipping rubocop installed but without any
default wiring becomes a 'standard'.

However, given that, then I'm in agreement with dan and seth that it
simply needs to get dropped and users need to chef gem install or bundle
install the exact version they desire.

—
Reply to this email directly or view it on GitHub
#320 (comment).

[charlesjohnson]

+1 here for keeping Rubocop and providing sane defaults as well, in case that's not clear by the PR itself. The counter-arguments are compelling but it still seems a least-worst option.

[kramvan1]

+1 for keeping rubocop (convenient to have tools available) ...as for providing defaults, that's nice but not necessary.

[vinyar]

+1 from me on sane default.

[danielsdeleo]

I know everyone wants a sane default, I do, too. But again, I don't have the slightest idea how that's possible with rubocop without significant downside:

• We just never upgrade it until the end of time, so that the good defaults we pick today are good forever.
• Or accept that every rubocop upgrade could have a terrible UX, because the sane defaults changed in response to some new rubocop rule so you have to apply the new sane defaults to every cookbook you have (also you have to preserve users customizations somehow).
• Or go back to using bundler for everything and every cookbook can use whatever version of rubocop it wants to pin. But then it doesn't need to be in ChefDK because you're gonna bundle install it.

[vinyar]

I'm with you Dan. For example, some time ago the name of the 'todo' file changed.

The generated .rubocop.yml doesn't need to have all of the rules activated, they can (and perhaps should) all be there commented out. Just having the scaffolding is a great step forward with much less overhead.

# inherit_from: .rubocop_todo.yml
# LineLength:
#   Max: 200
# etc...

[lamont-granquist]

Just ran across someone wrapping rubocop into their own gem with their own default style:

https://github.com/reevoo/reevoocop

[mattstratton]

Out in the field, working with Chef newbies (who are also Ruby newbies), I've been finding a lot of value with Rubocop. As @charlesjohnson mentioned, it has personally helped ME level up my Ruby as a non-coder, which a lot of our customers are. When I teach a POC to a group, I always use Rubocop (after giving them my own .rubocop.yml, which I stole from @charlesjohnson who I think stole it from @someara). I can see how this seems redundant or inappropriate for deep Chefs, who already are good at this stuff, or for a team that is already working. But for the "we are just getting started", everything we can do to make it easier and cleaner helps them move faster.

So I'm +1 for still shipping Rubocopy with the DK, but with at least a base .rubocop.yml that removes some of the more useless cops.

[jtimberman]

My suggestion:

Use rubocop --lint - so it only does lint checking and doesn't do any style checking, since there isn't even a single style guide for the community, and so many people disagree with the defaults in rubocop (hence the above discussion).

[kevindickerson]

RuboCop helps people learn Ruby, and makes folks who are new to the ecosystem happier writing code. Happy coders make happy code.

Iterating towards the most readable standard should be part of the journey. Everyone out there in the community has varying degrees of experience, and varying levels of success at achieving their goals from month to month. Really good teams are rare, and they don't really last that long. There's a reason why Times New Roman looks the way it does, and Helvetica looks the way it does. Readable code is more readable, and there are multiple contexts for readability.

I advocate starting with more firm rules, and relaxing or altering them over time as needed. Starting with a style guide is certainly better than none and will result in more readable code, which means fewer errors over time.

[lamont-granquist]

The --lint checks are the ones that actually raise red flags to programming errors. The use of %w{} vs. %w() is just a bikeshed that doesn't catch any programming errors. And the most useful errors to fix aren't going to be pointed out by static analysis -- if rubocop could turn someone into a software developer that'd be great, but its slightly more involved than that.

[someara]

A little bike shedding can be a good thing.

%w(this works)
%w{this works}
%w[this works]
%w[this works]
%w|this works|
%w$ this works $
%w^ this works^
%w! this works !

-s

On Mon, Mar 2, 2015 at 11:55 PM, Lamont Granquist notifications@github.com
wrote:

The --lint checks are the ones that actually raise red flags to
programming errors. The use of %w{} vs. %w() is just a bikeshed that
doesn't catch any programming errors. And the most useful errors to fix
aren't going to be pointed out by static analysis -- if rubocop could turn
someone into a software developer that'd be great, but its slightly more
involved than that.

—
Reply to this email directly or view it on GitHub
#320 (comment).

[danielsdeleo]

It seems like rubocop can now run in an opt-in mode if you use configuration like this:

AllCops:
  DisabledByDefault: true

cf. https://github.com/bbatsov/rubocop/blob/master/README.md#enabled

So I think we can now actually make progress on this and have a default config that won't break the universe on every rubocop upgrade. This solves my number one objection to rubocop. I would be happy with a config that makes all the rules opt-in and does not enable the bike shed garbage rules. And for the love of all that is good, never enable the string literal thing.

[schisamo]

Turning off all cops by default doesn't seem ideal as it disables the lint cops which catch many code errors. The best long term solution is a shipping a "chefstyle" wrapper for RuboCop that works in a similar way to https://github.com/fnichol/finstyle. I believe @fnichol and @robbkidd began scheming this at the community summit hack day.

It would be nice to have 2 sane sets of rules:

• one set for validating Chef's various Ruby projects
• one set for validating cookbooks. This would also allow us to begin deprecating Foodcritic...any Foodcritic rules that should be preserved can be recreated as custom RuboCop cops.

A final thought - we should listen to the words of wisdom from our community, customers and Chef's customer facing teams: most new Chef users find a lot of value in RuboCop (even with its warts). Project maintainers and more experienced users also benefit from allowing a tool to tell new contributors when their code is not up to par! Code style and consistency is important.

[danielsdeleo]

My point is you disable everything, then enable a set of things that are actually good (personally, the lint rules are the only ones I actually like). It'll probably make the rubocop yaml pretty big, but the benefit is that when a new version of rubocop comes out, it doesn't enable a bunch of new rules that fail your previously passing builds. Thus we can actually use rubocop as part of a stable project that people can upgrade with confidence. The opt-out mode of configuration is not acceptable because new rules can fail your builds on upgrade, which is not acceptable for stable software.

[lamont-granquist]

me and @thommay are also talking about a 'chefstyle' for chef/chef at some point, and @tas50 was interested in a chefcop for cookbook style, which would be the thing i'd suggest shipping with chef-dk since it would be tuned for cookbooks and not for chef/chef.

[thommay]

Yeah, as Lamont said we were discussing chefstyle and chefcop; if we can start from everything disabled and build up incrementally that seems like goodness.

[danielsdeleo]

With the addition of opt-in configuration mode, I think we can get pretty close to optimal with rubocop. Things that I predict would still be less-than-perfect:

• Have to be very clear that we're only supporting rubocop with our config, and if you disable the opt-in mode you're on your own for dealing with breakages caused by upgrades.
• With opt-in mode, it looks like we have to enable every rule individually, so the generated rubocop config would be pretty big, and we'd probably have to include commented out sections for all the rules we're disabling. Users who like the bikeshed parts of rubocop probably would need to use custom generators or do a lot of fiddling.
• Rubocop's config search doesn't match ChefDK/knife
• probably more stuff that I can't anticipate in advance

Despite that, at this point I think it's still a win to start by putting a rubocop config in the generators, so we can avoid issues like #611

[lamont-granquist]

Yeah the problems with the massive config file is what leads me to want to bundle that up in a gem and ship it as chefcop so that users don't see a default 8,000-line long .rubocop.yml generated in every cookbook...

[tas50]

Can this get closed now that we have chefcop applied to both chef and ohai. A new PR applying chefcop here seems like it would make more sense. Ping Mr. Rubocop @lamont-granquist

[danielsdeleo]

@tas50 So this ticket is mostly about making our generated cookbooks (and Berksfile and Policyfile.rb files) rubocop-valid. I had thought we settled on making two rubocop derivatives--one for our ruby applications (which is chefstyle) and another one with our minimum recommended set of rules for cookbooks and such (not started AFAIK). Now that we have chefstyle we should be able to take a quick look to see if we think it's a thing we'd recommend to users for the latter case and re-evaluate that plan.

In either case we'd need to do at least a little more work, so this isn't done. But maybe we replace it with a new ticket or a feedback.chef.io thing? I don't have strong opinions on how we track it.

[lamont-granquist]

So, chefstyle is still about our code, not user code, and that isn't going to change for awhile, its still not done. It would probably be better to fork off a cookstyle or just chefcop that was recommended rulesets for cookbooks.

Here's the TODO list for chefstyle right now (these are offenses which chefstyle disables by default but we haven't made a decision on if or how to enable):

5502   Style/HashSyntax
963    Style/BracesAroundHashParameters
749    Style/BlockDelimiters
695    Style/AlignParameters
425    Style/DotPosition
281    Style/LeadingCommentSpace
196    Style/MethodCallParentheses
185    Style/DeprecatedHashMethods
183    Style/EmptyLiteral
180    Lint/UselessAssignment
164    Style/AndOr
161    Style/RegexpLiteral
159    Lint/DeprecatedClassMethods
153    Style/RedundantSelf
152    Style/NegatedIf
140    Style/PerlBackrefs
130    Style/SymbolProc
128    Style/ClassCheck
120    Style/Alias
111    Style/ClassAndModuleChildren
110    Style/StringLiteralsInInterpolation
106    Style/MutableConstant
99     Style/CommentIndentation
98     Lint/ParenthesesAsGroupedExpression
95     Style/ConditionalAssignment
93     Style/LineEndConcatenation
89     Style/RedundantReturn
87     Style/AlignArray
84     Style/NumericLiterals
82     Lint/AmbiguousRegexpLiteral
79     Style/Lambda
74     Style/GuardClause
74     Style/ZeroLengthPredicate
73     Lint/AssignmentInCondition
72     Style/UnneededInterpolation
71     Style/RedundantBegin
70     Style/NestedParenthesizedCalls
70     Style/Semicolon
66     Style/MultilineBlockLayout
63     Style/MethodName
63     Style/SpecialGlobalVars
60     Style/BarePercentLiterals
60     Style/ParallelAssignment
53     Style/PredicateName
52     Style/BlockComments
52     Style/UnneededPercentQ
50     Style/IndentArray
48     Style/AccessorMethodName
47     Style/Proc
45     Style/BlockEndNewline
45     Style/CommentAnnotation
43     Style/EachWithObject
39     Style/RaiseArgs
38     Style/Next
37     Style/RedundantParentheses
30     Style/CaseEquality
30     Style/GlobalVars
30     Style/IdenticalConditionalBranches
28     Style/IfInsideElse
27     Performance/RedundantBlockCall
27     Style/ClassVars
27     Style/EmptyElse
27     Style/FirstParameterIndentation
27     Style/SpaceAfterNot
26     Style/UnlessElse
25     Style/ClassAndModuleCamelCase
25     Style/SingleLineMethods
19     Lint/IneffectiveAccessModifier
18     Performance/Detect
18     Performance/StringReplacement
18     Style/Not
17     Style/ClosingParenthesisIndentation
17     Style/SpaceBeforeComma
16     Style/CaseIndentation
15     Lint/ShadowingOuterLocalVariable
15     Style/SingleLineBlockParams
14     Style/SpaceBeforeSemicolon
12     Style/NilComparison
12     Style/VariableInterpolation
11     Style/DefWithParentheses
10     Style/ModuleFunction
9      Lint/UselessAccessModifier
9      Lint/Void
8      Style/AccessModifierIndentation
8      Style/MultilineTernaryOperator
8      Style/NonNilCheck
8      Style/RedundantException
8      Style/SpaceInsideStringInterpolation
8      Style/WhileUntilModifier
7      Style/ConstantName
7      Style/RescueModifier
7      Style/SelfAssignment
7      Style/SpaceAfterSemicolon
6      Lint/Eval
6      Lint/NestedMethodDefinition
6      Performance/Casecmp
6      Performance/RedundantMatch
6      Style/AsciiComments
6      Style/MultilineIfThen
6      Style/MultilineMethodCallIndentation
6      Style/OpMethod
5      Performance/RedundantMerge
5      Style/FileName
4      Lint/UnderscorePrefixedVariableName
4      Style/IndentAssignment
4      Style/SpaceBeforeComment
3      Style/MultilineBlockChain
2      Performance/TimesMap
2      Style/VariableName
1      Performance/Count
1      Performance/RangeInclude
1      Style/OptionalArguments
1      Style/StructInheritance

[lamont-granquist]

for future posterity, we went with cookstyle:

https://github.com/chef/cookstyle

it is for cookbook usage. the similar 'chefstyle' gem is for chef/chef and related ruby code.