Live data from Hacker News

Yoda conditions

en.wikipedia.org

51–60 of 116 posts

Re: Yoda conditions

#51

Earlier quoted context omitted.

The greatest difficulty with code is not in writing it but in reading it.

if/unless is pretty common in natural language for good reason. I find it far more readable than prefix, block-form if for the simple case of one-line results with no alternative branch.,

Agreed. Particularly useful for for constructs like:

  def do_stuff()
    return unless stuff_enabled?

    ...
  end

Re: Yoda conditions

#52

All linters and C compilers emit a warning when an assignment is made in a condition. There are zero reasons to use that ugly and unnatural Yoda notation in 2019.

I think this is reasonable readable: while ((status = systemcall(...)) != SUCCESS) { do something with status; } Leave a comment there explaining the assignment. Likewise: if ((status = systemcall(...)) != SUCCESS) goto error; Or something like that. I don't understand the hate, just make sure it's obvious what you're doing.

This would achieve the same but is far more readable:

   while(status != SUCCESS) {
      status = syscall(...);
      // do something with status
   }

Re: Yoda conditions

#54

Earlier quoted context omitted.

I think this is reasonable readable: while ((status = systemcall(...)) != SUCCESS) { do something with status; } Leave a comment there explaining the assignment. Likewise: if ((status = systemcall(...)) != SUCCESS) goto error; Or something like that. I don't understand the hate, just make sure it's obvious what you're doing.

This would achieve the same but is far more readable: while(status != SUCCESS) { status = syscall(...); // do something with status }

Only if status is initialised to something other than SUCCESS.

Re: Yoda conditions

#55

All linters and C compilers emit a warning when an assignment is made in a condition. There are zero reasons to use that ugly and unnatural Yoda notation in 2019.

I think this is reasonable readable: while ((status = systemcall(...)) != SUCCESS) { do something with status; } Leave a comment there explaining the assignment. Likewise: if ((status = systemcall(...)) != SUCCESS) goto error; Or something like that. I don't understand the hate, just make sure it's obvious what you're doing.

It’s traditional to build these kinds of loops in C, e.g.:

    int c;
    while((c = getopt(argc, argv, argstr)) >= 0) {...}
I’d say it’s acceptable, and Python is adding syntax so it can mix assignments and checks.

Re: Yoda conditions

#56
When your only hammer is C, everything looks like a toe.

Is there a shorter way of saying, "the wrong solution to the right problem"?

Re: Yoda conditions

#57
post #43

One example of a large code base that uses this is WordPress (PHP).

Good job duplicating that second paragraph of the linked article.

Argh, sorry I missed that, I skipped over the intro and looked at the examples.

EDIT: to be fair, this sentence was added today [1]. Not sure if it would have been there when I opened the tab earlier.

[1] https://en.wikipedia.org/w/index.php?title=Yoda_conditions&t...

Re: Yoda conditions

#58

All linters and C compilers emit a warning when an assignment is made in a condition. There are zero reasons to use that ugly and unnatural Yoda notation in 2019.

I think this is reasonable readable: while ((status = systemcall(...)) != SUCCESS) { do something with status; } Leave a comment there explaining the assignment. Likewise: if ((status = systemcall(...)) != SUCCESS) goto error; Or something like that. I don't understand the hate, just make sure it's obvious what you're doing.

That's perfectly fine and arguably even better than the alternatives. The `a = b = c = 0;` format is also good.

But enabling it on the language level brings a large amount of risk and complexity just for what amounts to a micro-optimization.

Re: Yoda conditions

#59
post #16
post #4

Am I sure pretty any that linter warning a throw can of instead breaking flow the both of reading writing and.

Despite the name, it isn't referring to Yoda's grammar form, it's just reversing things around "and" and "or". If you really have a problem telling that "x == y" is the same as "y == x" I suggest coming to a deeper, more complete understanding of the equality operator as a commutative operator where the order doesn't matter rather than thinking of it as "variable is? value", as so many students clearly pick up accide…

I don't have a problem with 'equals' being commutative. My programming language does.

Re: Yoda conditions

#60
It should be noted that Yoda conditions originated at a time when compilers didn't warn about accidental assignment, and linters weren't that great or had poor compatibility.

More often than not, the first solution to a problem isn't the best, but the best solution would take a lot of tooling fixes.

The Yoda condition trick is a relic of the past, well past its usefulness and best left in its grave alongside Hungarian notation, macros for "inlining", #include "blah.c", goto, etc.

Post reply on HN