Smalltalk › Squeak › Squeak - Dev

Best practices question

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

14 messages Options

Louis LaBrunda

Best practices question

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:[hidden email] http://www.Keystone-Software.com

Bob Arning-2

Re: Best practices question

I prefer the first - it gets one case out of the way quickly.

Cheers,
Bob

On 10/23/13 10:12 AM, Louis LaBrunda 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
[hidden email] http://www.Keystone-Software.com

Tobias Pape

Re: Best practices question

On 23.10.2013, at 16:22, Bob Arning <[hidden email]> wrote:

> I prefer the first - it gets one case out of the way quickly.

I would say, it depends :)
If it is only one (or at most two) tests,
the first case,

but on the other hand, I try to stick to the rule

Only One Return per method, if possible

This helps following the control flow.

Best
-Tobias

>
> Cheers,
> Bob
>
> On 10/23/13 10:12 AM, Louis LaBrunda 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:[hidden email] http://www.Keystone-Software.com

signature.asc (1K) Download Attachment

Ben Coman

Re: Best practices question

In reply to this post by Bob Arning-2

Either. But in general use ^self rather than ^nil
so that it acts the same as the implicit ^self when you drop out the end of a method.

Bob Arning wrote:

I prefer the first - it gets one case out of the way quickly.

Cheers,
Bob

On 10/23/13 10:12 AM, Louis LaBrunda 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 <a class="moz-txt-link-freetext" href="callto://PhotonDemon">callto://PhotonDemon
[hidden email] http://www.Keystone-Software.com
  

Francisco Garau-2

Re: Best practices question

In reply to this post by Tobias Pape

I also prefer the first case as it is more readable.

The disadvantage is that you end up having a non local return. And running that same code from a block will fail when a=b.

- Francisco

On 23 Oct 2013, at 16:10, Tobias Pape <[hidden email]> wrote:

> On 23.10.2013, at 16:22, Bob Arning <[hidden email]> wrote:
>
>> I prefer the first - it gets one case out of the way quickly.
>
> I would say, it depends :)
> If it is only one (or at most two) tests,
> the first case,
>
> but on the other hand, I try to stick to the rule
>
> Only One Return per method, if possible
>
> This helps following the control flow.
>
> Best
> -Tobias
>
>
>>
>> Cheers,
>> Bob
>>
>> On 10/23/13 10:12 AM, Louis LaBrunda 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:[hidden email] http://www.Keystone-Software.com
>
>
>

Chris Muller-3

Re: Best practices question

In reply to this post by Ben Coman

> Either. But in general use ^self rather than ^nil
> so that it acts the same as the implicit ^self when you drop out the end of
> a method.

+1. Senders might want to cascade.

>
> Bob Arning wrote:
>
> I prefer the first - it gets one case out of the way quickly.
>
> Cheers,
> Bob
>
> On 10/23/13 10:12 AM, Louis LaBrunda 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:[hidden email] http://www.Keystone-Software.com
>
>
>
>
>
> ________________________________
>
>
>
>
>
>
>

Chris Muller-3

Re: Best practices question

In reply to this post by Louis LaBrunda

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
<[hidden email]> 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:[hidden email] http://www.Keystone-Software.com
>
>

Bob Arning-2

Re: Best practices question

In reply to this post by Chris Muller-3

Except that cascade is not affected by the return value...

self foo; bar.

cares not what is returned by foo.

I think there was a discussion some time ago that self might not have been the best default return value. YMMV.

Cheers,
Bob

On 10/23/13 2:05 PM, Chris Muller wrote:

Either. But in general use ^self  rather than ^nil
so that it acts the same as the implicit ^self when you drop out the end of
a method.

+1.  Senders might want to cascade.

Bob Arning wrote:

I prefer the first - it gets one case out of the way quickly.

Cheers,
Bob

On 10/23/13 10:12 AM, Louis LaBrunda 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
[hidden email] http://www.Keystone-Software.com





________________________________

Chris Muller-3

Re: Best practices question

On Wed, Oct 23, 2013 at 1:11 PM, Bob Arning <[hidden email]> wrote:
> Except that cascade is not affected by the return value...
> self foo; bar.
>
> cares not what is returned by foo.

Your example assumes the send is to self. I was thinking of an
example where it was sent from another class:

louisObject methodWhichReturnsNilInsteadOfSelf
message1 ;
message 2

can no longer be done. Before, it could.

But, ok, you're right, it's not specifically cascading that is affected.. :)

>
> I think there was a discussion some time ago that self might not have been
> the best default return value. YMMV.
>
> Cheers,
> Bob
>
> On 10/23/13 2:05 PM, Chris Muller wrote:
>
> Either. But in general use ^self rather than ^nil
> so that it acts the same as the implicit ^self when you drop out the end of
> a method.
>
> +1. Senders might want to cascade.
>
> Bob Arning wrote:
>
> I prefer the first - it gets one case out of the way quickly.
>
> Cheers,
> Bob
>
> On 10/23/13 10:12 AM, Louis LaBrunda 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:[hidden email] http://www.Keystone-Software.com
>
>
>
>
>
> ________________________________
>
>
>
>
>
>
>
>
>
>
>
>

Bob Arning-2

Re: Best practices question

Well, the comments about returning self rather than nil in Louis's example seemed to assume the rest of his code would return self, but that code was not in evidence, so who knows.

On 10/23/13 4:46 PM, Chris Muller wrote:

On Wed, Oct 23, 2013 at 1:11 PM, Bob Arning [hidden email] wrote:

Except that cascade is not affected by the return value...
self foo; bar.

cares not what is returned by foo.

Your example assumes the send is to self.  I was thinking of an
example where it was sent from another class:

  louisObject methodWhichReturnsNilInsteadOfSelf
    message1 ;
    message 2

can no longer be done.  Before, it could.

But, ok, you're right, it's not specifically cascading that is affected..  :)

I think there was a discussion some time ago that self might not have been
the best default return value. YMMV.

Cheers,
Bob

On 10/23/13 2:05 PM, Chris Muller wrote:

Either. But in general use ^self  rather than ^nil
so that it acts the same as the implicit ^self when you drop out the end of
a method.

+1.  Senders might want to cascade.

Bob Arning wrote:

I prefer the first - it gets one case out of the way quickly.

Cheers,
Bob

On 10/23/13 10:12 AM, Louis LaBrunda 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
[hidden email] http://www.Keystone-Software.com





________________________________

Louis LaBrunda

Best practices question

In reply to this post by Chris Muller-3

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
><[hidden email]> 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:[hidden email] http://www.Keystone-Software.com
>>
>>
>

-----------------------------------------------------------
Louis LaBrunda
Keystone Software Corp.
SkypeMe callto://PhotonDemon
mailto:[hidden email] http://www.Keystone-Software.com

Casey Ransberger-2

Re: Best practices question

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 <[hidden email]> 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
><[hidden email]> 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:[hidden email] http://www.Keystone-Software.com
>>
>>
>
-----------------------------------------------------------
Louis LaBrunda
Keystone Software Corp.
SkypeMe callto://PhotonDemon
mailto:[hidden email] http://www.Keystone-Software.com

Bob Arning-2

Re: Best practices question

go for it.

Cheers,
Bob

On 10/24/13 10:59 PM, Casey Ransberger wrote:

And I want the up-arrow glyph back, too

Nicolas Cellier

Re: Best practices question

If you look at the glyphs of most StrikeFont, you'll see that the arrows are there...

It's just a matter of properly connecting them with a well crafted characterToGlyphMap.

But this shall be a Preference...

2013/10/25 Bob Arning <[hidden email]>

go for it.

Cheers,
Bob

On 10/24/13 10:59 PM, Casey Ransberger wrote:

And I want the up-arrow glyph back, too