DEV Community

Discussion on: Yoda Conditions (From the office)

Collapse
 
tinussmit profile image
Tinus Smit

To me this seems like a whole lot of debate for something that's really not that big of a deal.

To me it looks like people

  • Write code directly in production without testing it themselves (a bigger problem than yoda or no-yoda).
  • Write code without testing / verifying the logic before handing it over to the users (the "if it compiles it works" mindset).

Both of these would make this issue seem much bigger than it really is. Additionally, this only works if one of the things being compared to is a constant (like a number). It likely yields no benefit if both items are variables.

If your language does not insist that the if statement has to be a Boolean expression (the statement has to yield true or false, otherwise you get a compiler / syntax error), then you simply have to be a little more vigilant.
I have to alternate between C# and JavaScript at times, and I've made the mistake in JavaScript once or twice. But I also pick it up almost immediately when I do a simple test of the code by running it. Understanding the language being used a bit more intimately would result in some sort of "preventative" mindset whereby you'd know if you're writing an if statement that your syntax requires == instead of = (in the cases of languages like C#, JavaScript, and many more).

A better alternative might even be to create methods with descriptive names that return a true or false where you have the freedom to create a more readable and testable bit of code.

Collapse
 
thomasjunkos profile image
Thomas Junkツ

To me this seems like a whole lot of debate for something that's really not that big of a deal.

Couldn't agree more.

Collapse
 
anastasionico profile image
anastasionico • Edited

hahaha yes.

what about readability vs reliability? that is a more interesting debate

Collapse
 
anastasionico profile image
anastasionico

Thanks for the comment and I definitely agree with you.

More than Yoda vs no Yoda, I point that I tried to make in the article is readability vs reliability.

I went against what uncle Bob said in his book because I think we should give priority to reliability.

What do you think?

Collapse
 
tinussmit profile image
Tinus Smit

I actually don't think those are mutually exclusive.

In my opinion...

Readability is about descriptive names (methods, classes, variables etc.), following conventions in naming; anything that helps a human understand the code. Can I hand this to another developer that doesn't have all my context and will they be able to understand the code soon? That's the question readability answers.

Reliability is about stuff like defensive coding, error handling, null checking; stuff that ensures that the code works as intended with the fewest possible crashes. Has the code been tested with a variety of scenarios and are the results what we intended each time / handled if not? That's what reliability answers.

There's room for both to exist at the same time.

You'll notice that I mention testing a lot, and that's a very key part of making sure that code is reliable. Untested code works in theory, but testing measures the reliability 😃