[..snip..] > 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. >> >> > The only idiomatic part of the and/or one that we'd get rid of is failure > statements: do_something() or raise "Noooo!!!". I'm willing to drop that > for the slightly more wordy: > > if !do_something() > raise "Nooooo!!!!" > end > > In fact, I often like that construction better because it is more future > proof. If it turns out that you need to add extra actions in the error > case, then there isn't any need to perform refactor first. >
It is possible to get back most idiomatic constructions by slightly tweaking the cops. In fact it is rather easy to do so, and here[1] is a custom cop that checks for And/Or only in conditionals. - I feel that the boolean control flow idiom is actually useful. A pattern that I have seen often in code is of the type unless x = mymethod() x.do_something end Which falls foul of Lint/AssignmentInCondition I think that it would be better written as `x = mymethod() and x.do_something` rather than `(x = mymethod()) && x.do_something` which is recommended in the ruby style guide from rubocop if we restrict and/or to purely control flow operators. [1] https://github.com/vrthra/puppet/commit/07cced3157a957b1b49de00a34da075af580fad7 -- 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/d3442dc7-2193-44aa-a000-18ecc2327082%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
