Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Yoda Conditions

en.wikipedia.org

Post reply on HN
Print view View original

1–10 of 83 posts

Re: Yoda Conditions

#2

Post by rocky1138 »

I don't follow this convention, but something I do follow is naming things by type first. This makes it really easy to find in a long list of files in a folder.

Example: plantArrowhead, plantGuzmania, plantMarmo vs. arrowheadPlant, guzmaniaPlant, marmoPlant.

Re: Yoda Conditions

#3

Post by paol »

Don't do this.

In languages where accidental assignment is possible (i.e. writing if(a=b) when you meant if(a==b) ), configure the compiler or linter to emit a warning in this situation.

For example in C, GCC will complain about this when compiling with -Wall, which you should be using anyway.

Re: Yoda Conditions

#4

Post by koolba »

A similar but arguably more useful version of this is when you have two variables, one of which may be null. Traditionally you issue an if-condition test using the variable user input as the left operand but switching it handles the null case automatically.

Ex:

    Foo SOME_CONSTANT = ;

    Foo userSuppliedInput = ;

    // This can raise an null pointer exception
    if (userSuppliedInput.isEquals(SOME_CONSTANT) {
        // ...
    }

    // This can't raise a null pointer exception (assuming isEquals handles nulls properly):
    if (SOME_CONSTANT.isEquals(userSuppliedInput) {
        // ...
    }

Re: Yoda Conditions

#5

Post by michaelmior »

paol wrote: post #3

Don't do this. In languages where accidental assignment is possible (i.e. writing if(a=b) when you meant if(a==b) ), configure the compiler or linter to emit a warning in this situation. For example in C, GCC will complain about this when compiling with -Wall, which you should be using anyway.

While I don't disagree, curious to hear your reasoning for not doing this.

Re: Yoda Conditions

#6

Post by brianwawok »

paol wrote: post #3

Don't do this. In languages where accidental assignment is possible (i.e. writing if(a=b) when you meant if(a==b) ), configure the compiler or linter to emit a warning in this situation. For example in C, GCC will complain about this when compiling with -Wall, which you should be using anyway.

Eh, I think it is good in Java in cases where Null input is possible.

Re: Yoda Conditions

#7

Post by mirekrusin »

paol wrote: post #3

Don't do this. In languages where accidental assignment is possible (i.e. writing if(a=b) when you meant if(a==b) ), configure the compiler or linter to emit a warning in this situation. For example in C, GCC will complain about this when compiling with -Wall, which you should be using anyway.

Exactly, and use 'if ((a = b)) ...' in those rare cases when it's appropriate.

Re: Yoda Conditions

#8

Post by mikeash »

michaelmior wrote: post #5
paol wrote: post #3

Don't do this. In languages where accidental assignment is possible (i.e. writing if(a=b) when you meant if(a==b) ), configure the compiler or linter to emit a warning in this situation. For example in C, GCC will complain about this when compiling with -Wall, which you should be using anyway.

While I don't disagree, curious to hear your reasoning for not doing this.

It's unnatural, confusing to read, and won't save you anyway in cases where you're comparing two variables.

It's OK if your tools absolutely can't diagnose accidental if(a = b), but it should be the last resort.

Re: Yoda Conditions

#10

Post by mikeash »

koolba wrote: post #4

A similar but arguably more useful version of this is when you have two variables, one of which may be null. Traditionally you issue an if-condition test using the variable user input as the left operand but switching it handles the null case automatically. Ex: Foo SOME_CONSTANT = ; Foo userSuppliedInput = ; // This can raise an null pointer exception if (userSuppliedInput.isEquals(SOME_CONSTANT) { // ... } // This c…

Objective-C is really fun here. Messages to nil are no-ops which return zero, which for booleans results in false. Thus, the conditional works just fine either way:

  if([userSuppliedInput isEqual: SOME_CONSTANT]) { ...
If userSuppliedInput is nil, the isEqual: returns false, and it works.

It gets really fun when both might be nil:

  if([a isEqual: b]) { ...
If a and b are both nil, then they're conceptually equal, but isEqual: still returns false because it's a mindless "always return 0 for messages to nil" thing that doesn't even look at any parameters passed in.
Post reply on HN