Re: [Pharo-dev] Rationale behind the "ifTrue:/ifFalse: returns instead of and:/or:'s" rule

> 2) I just want to know why someone created such rule :). Because the author > of the last update of the initialize method is Marcus :) Probably to stop people from writing code like this: (borderColor isColor and: [ borderColor isTranslucentButNotTransparent ]) ifTrue: [ ^ true ].

Re: [Pharo-dev] Rationale behind the "ifTrue:/ifFalse: returns instead of and:/or:'s" rule

> > 1) it’s not only about removing. Maybe we should detect complicated boolean > expressions that return something and suggest to break them down. No idea… > 2) I just want to know why someone created such rule :). Because the author > of the last update of the initialize method is Marcus :)

Re: [Pharo-dev] Rationale behind the "ifTrue:/ifFalse: returns instead of and:/or:'s" rule

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" wrote: On

Re: [Pharo-dev] Rationale behind the "ifTrue:/ifFalse: returns instead of and:/or:'s" rule

> On 7 Apr 2017, at 12:01, Esteban Lorenzano wrote: > > >> On 7 Apr 2017, at 11:23, marcus.den...@inrira.fr >> > > wrote: >> >>> >>> On 7 Apr 2017, at 10:33, Yuriy Tymchuk

Re: [Pharo-dev] Rationale behind the "ifTrue:/ifFalse: returns instead of and:/or:'s" rule

> On 7 Apr 2017, at 11:59, Esteban Lorenzano wrote: > >> >> On 7 Apr 2017, at 10:33, Yuriy Tymchuk wrote: >> >> Hi, there is a rule that suggests to use and/or boolean operations instead >> of multiple returns. >> >> For example it suggests agains

Re: [Pharo-dev] Rationale behind the "ifTrue:/ifFalse: returns instead of and:/or:'s" rule

> On 7 Apr 2017, at 10:33, Yuriy Tymchuk 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 > >

Re: [Pharo-dev] Rationale behind the "ifTrue:/ifFalse: returns instead of and:/or:'s" rule

2017-04-07 11:23 GMT+02:00 marcus.den...@inrira.fr : > I really do not like the complex boolean expressions… my brain can > understand the “check and return” guards extremely fast: > > backgroundColor ifNil: [ ^ true ]. > (backgroundColor

Re: [Pharo-dev] Rationale behind the "ifTrue:/ifFalse: returns instead of and:/or:'s" rule

> On 7 Apr 2017, at 10:33, Yuriy Tymchuk 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 > >

Re: [Pharo-dev] Rationale behind the "ifTrue:/ifFalse: returns instead of and:/or:'s" rule

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

Re: [Pharo-dev] Rationale behind the "ifTrue:/ifFalse: returns instead of and:/or:'s" rule

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

[Pharo-dev] Rationale behind the "ifTrue:/ifFalse: returns instead of and:/or:'s" rule

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: [