[–] kibwen link

One of the best bugs I've ever seen was in the game Dungeon Crawl Stone Soup. It's a roguelike, and a venerable old one at that, so the codebase is quite tangled and convoluted, with logic for everything in every corner. One of the worshippable gods in the game is Xom, god of chaos, whose effects are just as likely to kill their worshipers as to help them (frustrating for those who might actually want to win, but always good for a laugh). And somewhere in the main game loop was some bit of logic that was only ever supposed to activate while the player was actively worshiping Xom. Guess how this was accidentally implemented:

  if (you.religion = GOD_XOM) {
This actually made it to the live test server, where player save files are automatically upgraded to the most recent build, so anyone logging in immediately found themselves infallibly worshiping the god of chaos, every single tick of in-game time (renouncement is futile). Chaos indeed!

reply

[–] hashkb link

The real lesson is for language designers, who for some reason love using equals for assignment. Lisp got it right a hundred years ago and nobody learned.

reply

[–] dom96 link

There is nothing wrong with using equals for assignment, the language designers just have to disallow assignments in if conditions.

reply

[–] tel link

It's a little weird. lvalues and rvalues are different things so a biased symbol feels nice to me, <-, e.g.

reply

[–] junke link

One more corner case, instead of designing orthogonal features.

reply

[–] kazinator link

That's a cure worse than the disease. If I faced a false choice between = as an assignment operator or else accepting syntax that distinguishes statements and expressions, I'd just take the = operator.

reply

[–] nilved link

There's nothing wrong with using assignment in if conditions. For example, `if let Some(thing) = computation_that_may_fail { ... }`.

reply

[–] undefined link
[deleted]

reply

[–] cronjobber link

Hacker News is implemented in a dialect of Lisp designed by a guy who wrote multiple books on Lisp. Seems even lispers don't learn:

> The assignment operator is =. I was dubious about this, but decided to try it and see if I got used to it. It turns out to work well, even in prefix. Stripes stand out, which is why they get used on warning signs and poisonous animals.

http://www.paulgraham.com/arcll1.html

reply

[–] kazinator link

That is quite silly. I briefly contemplated this idea for TXR Lisp, but completely rejected it. The = function is numeric comparison, like in Common Lisp. You don't want to turn that into assignment. People used to Lisp dialects where = is numeric comparison will make the mistake:

  (if (= whatever whatever-else) (you-got-burned))
Arc code written by people used to Lisp dialects where = is a pure comparison function, or Arc code converted from other Lisp dialects, has to be carefully reviewed against this.

If I put this into a Lisp dialect, I would make the code walker issue a warning whenever the value of a (= ...) assignment is used, and provide an alternative assignment operator which doesn't have that warning.

reply

[–] marcosdumay link

Well, languages can either use another assignment operator or have type system that wont check that kind of statement. Both ways fix it.

In fact, it's not easy to have this kind of bug on your language. C just has it because people wanted to write stuff like `int a = b = 0`.

reply

[–] jordigh link

`int a <- b <- 0` or `int a := b := 0` would have worked just as well.

Programmers using equals for assignment is a bit of a misunderstanding of what the mathematical idiom "let x = 5" means. The assignment is signaled by "let", not by "=". In fact, several programming languages use "let" exactly for this purpose too.

reply

[–] kbenson link

There are useful cases for this. It's much less ambiguous in those cases if your language allows the definition of the variable in the same location, and scopes it. For example, Perl:

    use strict;
    use warnings;
    
    sub one { 1 }
    
    if ( my $one = one() ) {
        say $one; # prints 1
    }
    
    say $one; # compilation error, "Global symbol "$one" requires explicit package name"
This case is trivial, but when you want a temporary variable and don't want to clutter your scope, it can be useful.

That's not to say assignment and equivalence might not be better off with different operators, as noted by others here.

reply

[–] dbaupp link

Declaration and a (mutating) assignment are different: your example demonstrates that Perl signals the declaration with `my`, and other languages offer similar things like `if let ... = ... { ... }`

reply

[–] kbenson link

> Declaration and a (mutating) assignment are different

Yes, that's what I was trying to get at by saying definition, but not very clearly. It's one of the reasons I prefer languages to require and clearly indicate variable declaration in most cases.

reply

[–] brianwawok link

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

reply

[–] paol link

Yes, "foo".equals(bar) is useful in Java if bar can be null, but that's a different thing.

reply

[–] megawatthours link

I never got the Java argument. I would much rather fail early and noisily with an NPE than return false and let my program happily chug along when it wasn't expecting a null. If the value is intended to be nullable, I would use an optional.

reply

[–] PaulHoule link

I think it is better than if(x!=null && x.equals("y")

You have to take bits of concision where you can find them in Java.

reply

[–] busterarm link

Counterargument:

Do do this if the coding standards for the language/framework you're working in require it. Like WordPress.

reply

[–] sethrin link

Wordpress is a legacy procedural codebase and should not be used as an example of good development practices.

reply

[–] michaelmior link

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

reply

[–] paol link

This trick can only save people who remember to use it. Warnings emitted by tooling save everyone.

Also it's slightly awkward to read, as mentioned by others already.

reply

[–] mikeash link

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.

reply

[–] MikkoFinell link

Also clang warns "using the result of an assignment as a condition without parentheses".

reply

[–] mirekrusin link

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

reply

[–] efaref link

Even then I would prefer an explicit comparison:

    if ((a = b) != NULL) ...
I think Rust has a happy medium, where assignment evaluates to (), not the variable (important as this means you don't have an implicit borrow), but the idiom expressed here is usually replaced by:

    if let Some(thing) = fn_that_returns_option_thing() ...

reply

[–] devy link

What about PHP? It's in the coding standard in WordPress and Symfony... :(

reply

[–] paol link

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.

reply

[–] thefifthsetpin link

I'm fond of Yoda conditionals, but not for the commonly cited reasons. Mostly I just like that they promote the interesting/unpredictable part of the comparison to the front. I consider the safety from unexpected assignment, from null pointer exceptions, and the Star Wars reference all to be minor perks.

Take this example:

  function handle_request($http){
    if("OPTIONS" === $http.request.method){
      ...
    }else if("GET" === $http.request.method){
       ...
    }else if("PUT" === $http.request.method){
      ...
    }else if($http.request.method === "POST"){
      ...
    }
    ...
  }
Did you read $http.request.method four times? I bet not. Some of you may have read it the first time; I wouldn't have. But to know that the fourth block handled POST requests I made you read to the end of the line. That makes it harder to scan the code looking for the section that you want to change. In production code that I've seen, the predictable side of a comparison is often quite long.

What's especially bizarre to me is the reason people give when advocating writing in the last style. Yes, it verbalizes nicely as "Otherwise, if the http request method post, then..." But who internally translates their code to English to understand it? COBOL was designed to read like natural language. Do you enjoy programming in COBOL? If English-like syntax is desirable for code readability, why don't modern programming languages prioritize English-like syntax, too?

Greek mathematics got stuck because it remained a verbal, pictorial activity, Moslem "algebra", after a timid attempt at symbolism, died when it returned to the rhetoric style, and the modern civilized world could only emerge —for better or for worse— ... thanks to the carefully, or at least consciously designed formal symbolisms that we owe to people like Vieta, Descartes, Leibniz, and (later) Boole.

-- Dijkstra,

reply

[–] YSFEJ4SWJUVU6 link

Just wrap the condition inside another pair of parentheses; that should get any linter off your back without needing to deal with the annoying flipped conditions – and if someone doesn't know the code base has a 100% coverage of Yoda conditions, they might just think there's a bug on the line when seeing it for the first time (unless you add an explanatory comment each time, at which point the assignment inside the condition has bought you nothing, as you might just lift it on a row of its own before the if statement).

C++, for instance however has language syntax to prevent confusion when using this idiom – declarations inside conditionals:

  if (auto val = getval())
    foo(val); // executed only if getval() returned something that evaluates to true
              // in a boolean context
Considering that PHP already has the useless var keyword, they might just adopt something similar in the future

  if (var $val = getval()) {}

reply

[–] efaref link

I've been coding for decades and I still find them jarring.

They're also a false sense of security as they won't catch:

    if $(value = $someOthervalue) ...

reply

[–] ghurtado link

I don't see at all how you could call this a Yoda Condition: it couldn't be written any other way, as it would cause a syntax error.

reply

[–] selfsimilar link

In PHP I like using Yoda Conditions because there's a common idiom of testing assignment in the conditional:

    if ($value = getSomeValue()) {
      // Safely use value
    }
Yoda Conditions defend nicely against accidents when '=' and '==' can be used legally this way and honestly you get used to reading them pretty quick.

reply

[–] pieterr link

"Refuctoring" is brilliant! Seen a lot of that lately. :-)

reply

[–] namanyayg link

A lot more of similar programming jargon by Jeff Atwood [1]

[1] https://blog.codinghorror.com/new-programming-jargon/

reply

[–] logfromblammo link

I was once officially reprimanded for using Yoda conditionals. That was at the same place that required this:

  if( booleanVariable == true )
  {
      ...
  }
  else if( booleanVariable == false )
  {
      ...
  }
  else
  {
      // Typically, this section would include an exact copy
      // of one of the above sections, as it was 3 years ago,
      // presumably to pad out the SLoC metrics.
  }
That place had its head so far up its own ass....

Equivalence is commutative. Please never complain about the order of its operands as "confusing" or "less readable". It just tells me that you're an ass, trying to enforce a coding convention that has no objective reason to exist.

reply

[–] jquast link

I wish python had case statements for this very problem. If the statement blocks can be defined by a common function signature, your example could use

  {'start':  fn_start,
   'stop': fn_stop,
  }.get(
    argv[1] if len(argv) > 1 else None,
    fn_undefined
  )(*args, **kwargs)
I used this in a demonstration terminal nibbles/worms video game clone, https://github.com/jquast/blessed/blob/master/bin/worms.py#L...

reply

[–] geofft link

I ran across a bug at $dayjob where someone was clearly trying to use Yoda conditions, but messed up differently:

    if "start" == argv[1]:
        ....
    else if "stop" == argv[1]:
        ....
    else if "reload":
        ....
    else if "status" == argv[1]:
        ....
I think it'd be harder to make this mistake with the conditions the right way around. (Also, never mind that the equality bug isn't even possible in Python.)

reply

[–] undefined link
[deleted]

reply

[–] mikeash link

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.

reply

[–] efaref link

Not sure I like the sound of that. It sounds like the floating point wat of "NaN != NaN".

reply

[–] koolba link

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 = <something-not-null>;

    Foo userSuppliedInput = <some-user-input-possibly-null>;

    // 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) {
        // ...
    }

reply

[–] kentt link

One of the worst parts of Ruby. I can see the argument that it could be better to have

  save if valid
rather than

  if valid
    save
  end
but what I see 9 times out of 10 is

  things.do each |thing|
    foo
    bar
    baz
  end if valid
or

really.long.thing.that.i.try.to.parse.in.my.head if acutally_almost_never_happens

which is harder to read since I read top to bottom / left to right, but the flow is bottom to top and right to left

reply

[–] kbenson link

This is something Ruby likely got form Perl,but they cribbed it wrong. Perl's post-conditionals only work on single statements, not blocks. You can use them for functional style statements though. I.e.

    # Not allowed
    for ( 1 .. 10 ) {
        say $_;
    } if 1;
    
    # Allowed
    map { say $_ } ( 1 .. 10 ) if 1;
The idea seems to be that a post-conditional should be simple and obvious by the time you've parsed the statement. A block makes it confusing, as does mixing post control structures

Post-loop structures have the same limitation:

    # Not allowed
    { say "foo"; say $_ } for ( 1 .. 10 );
    
    # Allowed
    say $_ for ( 1 .. 10 );
When used correctly, these can become very succinct and clear.

    my %data = get_data_record_hash("foo");
    
    $data{$_} = update_field(data{$_}) for ('field1','field4',other_field');
    
    # Compare to map, which normally you expect to return values
    map { $data{$_} = update_field(data{$_}) } ('field1','field4',other_field');
The single statement limitation keeps you from going wild in ways that are probably not useful to future readers of the code (including you).

reply

[–] Gaelan link

You can write gibberish in any language. You shouldn't kill useful features because they are sometimes misused.

reply

[–] yellowapple link

To clarify a bit: postfix conditionals actually originate from Perl, and are one of several things that Ruby inherited as a Perl descendant.

In Perl:

    if ($x > 0) { $y += $x }
versus:

    $y += $x if $x > 0;

reply

[–] nayuki link

I would say that the phrase "Yoda conditions" more appropriately describes Ruby's alternative form of if-statements:

    if x > 0:
        y += x
versus

    y += x if x > 0

reply

[–] codr4life link

Not worth the effort; modern compilers are very helpful with identifying these kinds of slip ups; and they weren't really that common to begin with, not common enough to warrant the attention and energy sucked into this never ending argument. It's a rule for the sake of having rules, like so many others.

reply

[–] alexeiz link

Yoda conditions suck. You don't compare a constant to a value of a variable to make sure that the constant has a certain value. Such comparison is backwards. Unfortunately it is extremely popular at Microsoft among C++ programmers. They seem to totally lack any sense of style. Sometime in the nineties the enforcement of Hungarian notation throughout the company had a long lasting damaging effect on their psyche they still can't recover from after all these years.

reply

[–] MilnerRoute link

I didn't know abut "Yoda conditions," and thought it was going to be those "reversed" if statements that were so startling when I'd started coding in Perl.

      $days = 28  if $month eq "February";

reply

[–] rocky1138 link

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.

reply

[–] pier25 link

ESLint has a rule to prevent this.

http://eslint.org/docs/rules/yoda

reply

[–] oli5679 link

Interesting idea this is.

reply