> On 7 Apr 2017, at 11:59, Esteban Lorenzano <[email protected]> wrote: > >> >> 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. >> >> What is the reasoning behind the rule? Does the suggested version run faster >> (i.e. is optimized ing some way?). > > I disagree with such rule. Is confusing and unnecessary. > > The “escape condition” is clearer and easier to understand. > And methods that are composed like this: > > a = x1 ifTrue: [ ^ r1 ]. > a = x2 ifTrue: [ ^ r2 ]. > … > etc. > > are very common because they are (again) legible and can be easily optimised > by the JIT. > > (they are even called “case methods” somewhere I do not remember :P)
of course better way to deal with this is to use double dispatch, but you cannot always do it ;) > > Esteban > >> >> Cheers. >> Uko
