On Tue, Aug 5, 2014 at 3:50 PM, rahul <[email protected]> wrote: > So to summarize, this is our plan for Rubocop: > > - We propose to enable AndOr cop in small chunks, giving preference to > those files/directories that are heavily in development. > - For AndOr, the conclusion seems to be to avoid keywords completely, and > ensure that the instances where they are used are changed do not hurt > readability. > - As a prototype, we have turned on AndOr on lib/pops directory PR 2892 >
Also a heads-up that for pull requests: 1) a week or so ago, we added a travis job that fails if any of the .rubocop.yml enabled cops report anything (these are just the cops that were uncontroversial at the beginning of this thread) 2) just now, I turned on houndci.com which will comment on pull requests based on the same configuration Note that hound *can* be configured with a separate config file of its own, but we don't have one, so it falls back to the .rubocop.yml. If we wanted to have a set of cops which triggered comments on the PRs, but didn't figure travis fails, we could get that by having a separate houndci.yml. Not sure what I think of that, but just putting the idea out there. Kylo > > On Tuesday, July 29, 2014 11:00:46 PM UTC-7, Kylo Ginsberg wrote: > >> On Tue, Jul 29, 2014 at 4:42 PM, Andy Parker <[email protected]> >> wrote: >> >>> Right now the PRs are doing a mechanical transformation to remove a >>> keyword that we don't want to use. What is missing is that it isn't >>> transforming the code into what later changes to that code should preserve. >>> Or put another way, if we got a PR that contained new code that looked like >>> that we would reject it, I think. It passes the test of not using >>> disallowed operators, but it doesn't pass the test of being written in a >>> form that a reader would expect. >>> >> >> I agree that the purely mechanical transformation applied to the >> genuinely flow control cases introduces constructs that would slow me down >> as a code reader (and that I'd be very unlikely to write). >> >> So are there objections to converting such cases to use 'if', etc? >> Personally I'd find that clearer and easier to read. And it would still >> allow us to eliminate the and/or keywords which we've identified as the >> source of some bugs/confusion. >> >> Kylo >> > -- > 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/ab872dad-c258-4e09-81b3-8c13f17bc968%40googlegroups.com > <https://groups.google.com/d/msgid/puppet-dev/ab872dad-c258-4e09-81b3-8c13f17bc968%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Kylo Ginsberg [email protected] *Join us at PuppetConf 2014 <http://www.puppetconf.com/>, September 20-24 in San Francisco* *Register by September 8th to take advantage of the Final Countdown <https://www.eventbrite.com/e/puppetconf-2014-tickets-7666774529?discount=FinalCountdown> * *—**save $149!* -- 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/CALsUZFEHveiiDug7xWBT%2BWo0PKR0V-FrGXF%3DE%3DY%3D9-KqLrh4Ag%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
