I'd go with the former, especially if the method is pretty short and
there's only one test. In most cases I'd probably be answering self, unless
the nature of the method is such that it should answer something else
(e.g., nil.)

In general I find the early return to be idiomatic and familiar from a lot
of other Smalltalk code, but to an extent this perception could be colored
by a personal aesthetic preference, so YMMV. And I want the up-arrow glyph
back, too :P


On Wed, Oct 23, 2013 at 2:39 PM, Louis LaBrunda
<Lou at keystone-software.com>wrote:

> Thank you everyone for your answers.
>
> Lou
>
> >Kent Beck refers to the former as "Guard Clause" in his BP book and
> >agrees with you about when to use it.
> >
> >I think it's good to only have returns at the top (guard clauses) or
> >bottom.  Not in the middle.
> >
> >
> >On Wed, Oct 23, 2013 at 9:12 AM, Louis LaBrunda
> ><Lou at keystone-software.com> wrote:
> >> Hi,
> >>
> >> I'm about to write a method where I need to test whether to do
> something or
> >> just get out.  What is the best practices way to do this?  For example:
> >>
> >> (a = b) ifTrue: [^nil].
> >> *The code that does the work*
> >>
> >> or:
> >>
> >> (a = b) ifFalse: [
> >>    *The code that does the work*
> >> ].
> >>
> >> I think the second is better style but I have used both.  Generally
> using
> >> the first when *The code that does the work* is long and the second
> when it
> >> is short.
> >>
> >> Is there any speed difference between them?  I doubt it but I thought I
> >> would ask anyway.
> >>
> >> Lou
> >> -----------------------------------------------------------
> >> Louis LaBrunda
> >> Keystone Software Corp.
> >> SkypeMe callto://PhotonDemon
> >> mailto:Lou at Keystone-Software.com http://www.Keystone-Software.com
> >>
> >>
> >
> -----------------------------------------------------------
> Louis LaBrunda
> Keystone Software Corp.
> SkypeMe callto://PhotonDemon
> mailto:Lou at Keystone-Software.com http://www.Keystone-Software.com
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131024/be04b4a0/attachment.htm