41–50 of 83 posts
Earlier quoted context omitted.
While I don't disagree, curious to hear your reasoning for not doing this.
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.
You can't force everyone who edits your code to have linters and warnings turned on. Not everyone follows bests practices.
Earlier quoted context omitted.
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 i…
Not sure I like the sound of that. It sounds like the floating point wat of "NaN != NaN".
NULL = NULL
Earlier quoted context omitted.
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.
The trick saves the person writing the code and anyone modifying it down the road. You can't force everyone who edits your code to have linters and warnings turned on. Not everyone follows bests practices.
Earlier quoted context omitted.
Eh, I think it is good in Java in cases where Null input is possible.
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.
Earlier quoted context omitted.
While I don't disagree, curious to hear your reasoning for not doing this.
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.
Re: awkwardness, it doesn't feel awkward at all to me; given that Erlang and Elixir use assignment for destructuring and pattern-matching, Yoda conditionals feel very natural to me in comparison.
For example, this is valid Elixir code:
foo = {1, 2}
bar = if {baz, 2} = foo do
525600
end
IO.inspect foo # prints {1,2}
IO.inspect bar # prints 525600
IO.inspect baz # prints 1Earlier quoted context omitted.
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 i…
Not sure I like the sound of that. It sounds like the floating point wat of "NaN != NaN".
After having done Swift for a while, I'm a big fan of using an option type so that "reference to object" is a different static type altogether from "reference to object, or nil."
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
In Perl:
if ($x > 0) { $y += $x }
$y += $x if $x > 0;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.
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 an…