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

[Gabriel Cotelli]

The Boolean expression is easier to extract methods with an intention
revealing name. The "case with returns " it's harder to automatically
refactor.

And if you get rid of the nils, it became easier to read and refactor. 😉

On Apr 7, 2017 07:06, "Yuriy Tymchuk" <yuriy.tymc...@me.com> wrote:


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


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


On 7 Apr 2017, at 10:33, Yuriy Tymchuk <yuriy.tymc...@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