2017-04-07 11:03 GMT+02:00 Nicolas Cellier <
nicolas.cellier.aka.n...@gmail.com>:
> Hi Yuriy,
> to me the first form is a list of simple rules.
> The second one is a complex expression
>
> You made an effort to keep the list format for the second expression,
> while violating traditional block formatting which would be
>
>
>
> ^ backgroundColor isNil
> or: [
> (backgroundColor isColor and: [ backgroundColor
> isTranslucentButNotTransparent ]) or: [
> borderColor isColor and: [ borderColor
> isTranslucentButNotTransparent ] ] ]
>
>
Sorry, premature post caused by missuse of tab key, traditional format
could be something like:
isTranslucentButNotTransparent
^ backgroundColor isNil
or:
[ (backgroundColor isColor and: [ backgroundColor
isTranslucentButNotTransparent ])
or:
[ borderColor isColor and: [ borderColor
isTranslucentButNotTransparent ] ] ]
Personnally, I like this indentation better.
It's still preserving the list of simple rules, and indicate a hierarchy
among the rules
But indentations sounds overkill and won't scale very high.
To me the first form is nearer the pattern matching style of a functional
language.
> I don't think that runtime optimization count at all in such choice.
>
> 2017-04-07 10:33 GMT+02:00 Yuriy Tymchuk <yuriy.tymc...@me.com>:
>
>> 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?).
>>
>> Cheers.
>> Uko
>>
>
>
