On 7 Apr 2017, at 12:01, Esteban Lorenzano <estebanlm@gmail.com> wrote:

On 7 Apr 2017, at 11:23, marcus.denker@inrira.fr <marcus.denker@inria.fr> wrote:

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.

+42

1) it���s not only about removing. Maybe we should detect complicated boolean expressions that return something and suggest to break them down.

2) I just want to know why someone created such rule :). Because the author of the last update of the initialize method is Marcus :)

Uko

Marcus