On Mon, Jul 14, 2014 at 12:56 PM, Kylo Ginsberg <[email protected]> wrote:
> HI all,
>
> We'd like to start using static analysis against the puppet code base both
> to catch certain classes of coding errors and to enforce best coding
> practices. Those are laudable goals of course, but there is plenty of room
> for opinions on what qualifies. This email is a request to solicit some
> opinions :)
>
> To kick the discussion off: at this point, we're leaning toward using
> rubocop for static analysis, identifying a set of checkers ('cops' in
> rubocop lingo) and then setting up some CI integration, either in travis-ci
> or houndci, to enforce those cops against PRs.
>
> Rahul Gopinath has put together a PR with an initial proposal of 'cops' we
> might use:
>
> https://github.com/puppetlabs/puppet/pull/2855
>
> There's some initial discussion in that PR but the tldr of the proposal is
> to enable these cops:
>
> Lint/UnreachableCode
> Lint/ConditionPosition
> Lint/UselessComparison
> Lint/LiteralInterpolation
> Lint/ElseLayout
>
> and then there's been some discussion on the PR around these two cops:
>
> Style/AndOr
> Lint/AssignmentInCondition
>
> Each of those two checks catch coding patterns which both are a source of
> some bugs and, at the same time are idiomatic in certain cases. So there's
> room for discussion on those two.
>
> And then there are a *bunch* more cops for a variety of style/lint checks
> which we could consider enabling in addition to the above. There's some
> documentation of the various cops in the rubocop yaml files at:
>
> https://github.com/bbatsov/rubocop/tree/master/config
>
> So, thoughts?
>
> Kylo
>
> --
> Kylo Ginsberg
> [email protected]
>
> *Join us at PuppetConf 2014 <http://www.puppetconf.com/>, September
> 20-24 in San Francisco*
> *Register by July 31st to take advantage of the Early Bird discount
> <https://puppetconf2014.eventbrite.com/?discount=EarlyBird> **--**save
> $249!*
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-dev/CALsUZFHmU%2B8aAHLNV3nu5HK98d4%2BEw0Ez-GBJZHpTD7gddSSJA%40mail.gmail.com
> <https://groups.google.com/d/msgid/puppet-dev/CALsUZFHmU%2B8aAHLNV3nu5HK98d4%2BEw0Ez-GBJZHpTD7gddSSJA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
I think it would greatly increase the quality of contributions if the
"cops" started catching things and failing the PR builds. Being picky with
what we start evaluating I think is the right call and what Andy and Rahul
were already working out.
--
Rob Reynolds
Developer, Puppet Labs
*Join us at PuppetConf 2014 <http://www.puppetconf.com/>, September
20-24 in San Francisco*
*Register by July 31st to take advantage of the Early Bird discount
<https://puppetconf2014.eventbrite.com/?discount=EarlyBird> **--**save $249!*
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/CAMJiBK4ZzCG_5Noa-3ctfcmgHCArXri6wqXUnbypeQ%3DK%3Dnxz_A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
