6 ms·
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
by paol 10y ago
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.
- michaelmior 10y agoWhile I don't disagree, curious to hear your reasoning for not doing this.
- mikeash 10y agoIt'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.
- akerro 10y agoIn some languages it's better to use it, eg. in Java you can go with: mString != null && mString.equals("test") or "test".equals(mString) They do the same, but the second one adds hidden `defensive programming` to prevent NPE in `equals`. Saves time AND code. Intended usage of if(a=b) should be written as if((a=b)). Don't know what tool you use at work or at home, but most static code analysers will point you that. Try SonarQube at least.
- scj 10y ago> It's unnatural, confusing to read ... I feel as if that can rephrased "Don't do it because it is not done." A left-hand side constant is a convention that can have practical benefits in limited cases. Which at least should merit consideration.
- mikeash 10y ago"Don't do it because it is not done" is a good reason unless you're working solo and are sure your code will never be seen by others. And even then, it's a good idea to stick to what's done so you don't accumulate bad habits for projects that do have others looking at the code.
- pasquinelli 10y agohow would you write a yoda conditional with two variables? which is the yoda conditional (a == b), or (b == a)?
- mikeash 10y agoYou can't if they're both mutable, since the whole idea of a yoda conditional is to put an immutable thing on the left side. What I meant was that you can't use them in that case, so it's a technique you can't use with 100% consistency.
- paol 10y agoThis 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.
- busterarm 10y agoThe 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.
- michaelmior 10y agoDoes it? You also can't force everyone who edits your code to follow your conventions.
- digler999 10y agoactually you can, depending on the management structure in an organization :)
- yellowapple 10y agoWarnings can only save people who bother to read them. Yoda conditionals save everyone trying to run or compile the code in question. It goes both ways ;) 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 1
- brianwawok 10y agoEh, I think it is good in Java in cases where Null input is possible.
- paol 10y agoYes, "foo".equals(bar) is useful in Java if bar can be null, but that's a different thing.
- brianwawok 10y agoNot really different. In fact is is mentioned on the Wikipedia page.
- PaulHoule 10y agoI 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.
- deleted 10y ago[deleted]
- megawatthours 10y agoI 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.
- xxs 10y agoJava8 optional is way slower (write a tree alike struct with optional for left/right/parent) and null checks are one of the free ones. (Hardware optimized)
- brianwawok 10y agoWell for 95% of Java's live, there was no such thing as Optional. So say untrusted user input.. many cases where it could be something or null. Yoda checking it was a nice way to save a null check.
- mirekrusin 10y agoExactly, and use 'if ((a = b)) ...' in those rare cases when it's appropriate.
- efaref 10y agoEven 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() ...
- hashkb 10y agoThe 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.
- dom96 10y agoThere is nothing wrong with using equals for assignment, the language designers just have to disallow assignments in if conditions.
- junke 10y agoOne more corner case, instead of designing orthogonal features.
- kibwen 10y agoIt's not a corner case if you do it right. For example, in C the assignment operator evaluates to the value of the right-hand side expression (so `int x = (y = 2);` initializes `x` to 2). But in Rust, the assignment operator always evaluates to `()` (a.k.a. "unit", the empty tuple), and trust me, this is how you want the language to work in the presence of pervasive move semantics and single ownership. Furthermore, nothing in Rust is "truthy": if-expressions accept a boolean and nothing else (this is also, IMO, exactly what you want in every language, but I'm sure others will disagree :P ). So `if x = 2 {` is a compiler error in Rust because `()` can't be coerced to a boolean (to say nothing of the fact that this reassignment would probably be a compiler error anyway because most variables in Rust are immutable). This doesn't require any acrobatics, it's just the natural fallout of how the rest of the language works.
- junke 10y agoThanks, that's indeed a sensible way to do that.
- tel 10y agoIt's a little weird. lvalues and rvalues are different things so a biased symbol feels nice to me, <-, e.g.
- MikkoFinell 10y agoAlso clang warns "using the result of an assignment as a condition without parentheses".
- kbenson 10y agoThere 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.
- dbaupp 10y agoDeclaration 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 ... = ... { ... }`
- kbenson 10y ago> 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.
- busterarm 10y agoCounterargument: Do do this if the coding standards for the language/framework you're working in require it. Like WordPress.
- sethrin 10y agoWordpress is a legacy procedural codebase and should not be used as an example of good development practices.
- busterarm 10y agoRegardless of your religious convictions, Wordpress still exists and that work has to be done by somebody. I'd rather it be done by people who care than those that don't.
- sethrin 10y agoHow is that a comment on coding standards or best practices? I'm afraid the arguments against procedural code are not religious. Procedural code provides poor encapsulation and modularity. If procedural code was all that great, we wouldn't have needed to have C++, C#, Java, and Objective-C, and any number of other derivative languages. Regardless of my or your opinions, WordPress is a legacy codebase. Procedural code today is all but completely discarded.
- devy 10y agoWhat about PHP? It's in the coding standard in WordPress and Symfony... :(