DEV Community

Discussion on: Whats the most irritating "if statement condition" that you've come across?

makiten profile image
Donald

Yeah, I guess it was ambiguous, but since they didn't know (and didn't like) ternary operators, you'd find the same thing just as if/else.

Although, I'd say the first one would be better. Something like,

isValid = validate(objMyObj).Result;
Thread Thread
moopet profile image
Ben Sinclair

It might be just me, but once I've got a variable name that implies it's a boolean, I want it to be a boolean. If isValid was some kind of object, for example, then it's going to be really confusing to see it in a debugging message later on, and I'm going to wonder what I broke.

Thread Thread
makiten profile image
Donald

In C#, you'd probably have a property like .Result or .IsValid, and although Result is ambiguous, I see it often enough, especially with async methods. To make it less ambiguous, validate() would be CheckIfObjIsValid(myObj).Result, but that's a debate about naming conventions (and part of why I made this post).

Thread Thread
scotthannen profile image
Scott Hannen • Edited on

Someone might read this and wonder why you split hairs over something seemingly trivial. But focus on these tiny decisions is critical. Even if they are subjective, they reflect someone thinking

  • This isn't good enough
  • This is good enough
  • That was good enough, but this is better.

and all for reasons that they've thought through. It costs seconds and pays minutes. It pays hours when it prevents introducing a bug or more complicated code or when someone else follows the good example. Code is made entirely of details. Code matters, therefore details matter.