Re: [Pharo-dev] Rationale behind the "ifTrue:/ifFalse: returns instead of and:/or:'s" rule

On 7 Apr 2017, at 10:33, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:

Hi, there is a rule that suggests to use and/or boolean operations instead of multiple returns.

For example it suggests agains using:

isTranslucentButNotTransparent

backgroundColor ifNil: [ ^ true ]. (backgroundColor isColor and: [ backgroundColor isTranslucentButNotTransparent ]) ifTrue: [ ^ true ]. (borderColor isColor and: [ borderColor isTranslucentButNotTransparent ]) ifTrue: [ ^ true ]. ^ false

Instead you should use:

isTranslucentButNotTransparent

^ backgroundColor isNil or: [ (backgroundColor isColor and: [ backgroundColor isTranslucentButNotTransparent ]) or: [ borderColor isColor and: [ borderColor isTranslucentButNotTransparent ] ] ]

And at least a few developers think that the suggested implementation is more complicated to comprehend.

I really do not like the complex boolean expressions… my brain can understand the “check and return” guards extremely fast: backgroundColor ifNil: [ ^ true ]. (backgroundColor isColor and: [ backgroundColor isTranslucentButNotTransparent ]) ifTrue: [ ^ true ]. (borderColor isColor and: [ borderColor isTranslucentButNotTransparent ]) ifTrue: [ ^ true ]. ^ false while for the nesting everything in one huge or: /and: expression I have to think. I always feel that replacing the “guard” style with complex nested booleans makes the code worse. I really would like to remove the rule. Marcus