On 2014-09-08 24:13, Andy Parker wrote:
On Fri, Aug 8, 2014 at 3:11 PM, Rahul Gopinath <ra...@puppetlabs.com
<mailto:ra...@puppetlabs.com>> wrote:
While correcting AndOr, I come across methods calls such as `if
value.is_a? FixNum or value.is_a? Integer`
How should we parenthesize it? is it `(value.is_a? FixNum) ||
(value.is_a? Integer)` or should it be `value.is_a?(FixNum) ||
value.is_a?(Integer)` ?
value.is_a?(FixNum)
Parens around the method arguments are the clearest fix and we should
put them in everywhere IMO :)
+1, except in internal DSL like logic where it reduces readability.
(The question is specific to boolean predicates since they make up
almost all of the method calls that interact with `and` and `or`)
Is there a preference here?
On Fri, Aug 8, 2014 at 9:56 AM, Andy Parker <a...@puppetlabs.com
<mailto:a...@puppetlabs.com>> wrote:
> On Thu, Aug 7, 2014 at 6:09 PM, Rahul Gopinath
<ra...@puppetlabs.com <mailto:ra...@puppetlabs.com>> wrote:
>>
>> While hacking rubocop, I found that I can get it to autocorrect even
>> more `Style/AndOr` violations if I replace the use of the `not`
>> keyword with `!` first. The Rubocop is able to do the necessary
>> changes automatically. So I think we should turn on the `Style/Not`
>> cop also for our code for three reasons
>> 1. It is essentially free, with rubocop able to supply the
entire set
>> of corrections in its autocorrect mode
>> 2. It is consistent without goal of avoiding keywords with confusing
>> precedence.
>
>
> I actually thought that not would have gone hand in hand with and/or.
> Doesn't it have the same precedence problems as and/or?
>
> Either way, I'm a +1 for adding in this rule too.
>
>>
>> 3. Rubocop autocorrect is the best we can hope for, since it ensures
>> that the AST resulting from the changes are same, and hence the
>> semantics of the new and old fragments are same. Hence we avoid bugs
>> that cold go undetected otherwise.
>> I also propose to turn on the `Style/SpaceAfterNot` which disallows
>> space after the operator `!` so that usage such as `! mymethod` is
>> flagged in favor or `!mymethod`
>>
>
> No space after ! is my preferred style. And I'll just stop any
style wars
> and say it is the preferred style of the codebase (I am
channelling the
> puppet code gods).
>
+1
- henrik
--
Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/
--
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/ls5j7a%249u3%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.
