On 7 Apr 2017, at 12:01, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 7 Apr 2017, at 11:23, marcus.denker@inrira.fr <mailto:marcus.denker@inrira.fr> <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>> wrote:
On 7 Apr 2017, at 10:33, Yuriy Tymchuk <yuriy.tymchuk@me.com <mailto: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