> On 7 Apr 2017, at 12:01, Esteban Lorenzano <[email protected]> wrote:
> 
> 
>> On 7 Apr 2017, at 11:23, [email protected] 
>> <mailto:[email protected]> <[email protected] 
>> <mailto:[email protected]>> wrote:
>> 
>>> 
>>> On 7 Apr 2017, at 10:33, Yuriy Tymchuk <[email protected] 
>>> <mailto:[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.
>>> 
>> 
>> 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
> 

Reply via email to