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.tymchuk@me.com> wrote: 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