[..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 puppet-dev+unsubscr...@googlegroups.com. 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.
