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
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] > <javascript:>> 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. For more options, visit https://groups.google.com/d/optout.
