> On 7 Apr 2017, at 10:33, Yuriy Tymchuk <[email protected]> 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
