Hard to parse method name? isUnresolved()

[Mike Edwards <mi...@gmail.com>]

Folks,

I have been bothered by the name of a common method in doing some debugging over the past couple of 
days - this note is suggesting a change and I'd like some opinions first.

The method in question is the isUnresolved()method.

Looks innocuous, until you see lots of statements like this one:

if (!composite.isUnresolved()) {

}

Now, it may just be me, but I have a hard time parsing out double negatives like "not Unresolved".
This MEANS "is Resolved", but the construction makes it hard for me to take in.

Why dont we have a method "isResolved()" for artifacts??  Then the statement would look like:

if (composite.isResolved()) {

}

....which I find crystal clear.

So, my suggestion is to add in a method isResolved() for all artifacts - and then we can start to 
get rid of the "double negative" tests.  We can keep isUnresolved() - if we're really checking for 
that state, then a method reflecting that state is better than the double negative too.  I see both 
usecases often and so the desire for two methods.


Yours,  Mike.

Re: Hard to parse method name? isUnresolved()

[ant elder <an...@gmail.com>]

On Sun, Apr 26, 2009 at 4:26 PM, Mike Edwards
<mi...@gmail.com> wrote:
> Folks,
>
> I have been bothered by the name of a common method in doing some debugging
> over the past couple of days - this note is suggesting a change and I'd like
> some opinions first.
>
> The method in question is the isUnresolved()method.
>
> Looks innocuous, until you see lots of statements like this one:
>
> if (!composite.isUnresolved()) {
>
> }
>
> Now, it may just be me, but I have a hard time parsing out double negatives
> like "not Unresolved".
> This MEANS "is Resolved", but the construction makes it hard for me to take
> in.
>
> Why dont we have a method "isResolved()" for artifacts??  Then the statement
> would look like:
>
> if (composite.isResolved()) {
>
> }
>
> ....which I find crystal clear.
>
> So, my suggestion is to add in a method isResolved() for all artifacts - and
> then we can start to get rid of the "double negative" tests.  We can keep
> isUnresolved() - if we're really checking for that state, then a method
> reflecting that state is better than the double negative too.  I see both
> usecases often and so the desire for two methods.
>
>
> Yours,  Mike.
>

+1, sounds good to me Mike.

   ...ant

Re: Hard to parse method name? isUnresolved()

[Simon Laws <si...@googlemail.com>]

On Sun, Apr 26, 2009 at 4:26 PM, Mike Edwards
<mi...@gmail.com> wrote:
> Folks,
>
> I have been bothered by the name of a common method in doing some debugging
> over the past couple of days - this note is suggesting a change and I'd like
> some opinions first.
>
> The method in question is the isUnresolved()method.
>
> Looks innocuous, until you see lots of statements like this one:
>
> if (!composite.isUnresolved()) {
>
> }
>
> Now, it may just be me, but I have a hard time parsing out double negatives
> like "not Unresolved".
> This MEANS "is Resolved", but the construction makes it hard for me to take
> in.
>
> Why dont we have a method "isResolved()" for artifacts??  Then the statement
> would look like:
>
> if (composite.isResolved()) {
>
> }
>
> ....which I find crystal clear.
>
> So, my suggestion is to add in a method isResolved() for all artifacts - and
> then we can start to get rid of the "double negative" tests.  We can keep
> isUnresolved() - if we're really checking for that state, then a method
> reflecting that state is better than the double negative too.  I see both
> usecases often and so the desire for two methods.
>
>
> Yours,  Mike.
>

The positive "isResolved" would seem to be clearer to me. Must be used
all over the place though so lots of changes.

Simon