5 ms·

To get you started, I'd like to compare my problems regarding `if <Constant> = <Variable>` with yours. This assumes you aren't the kind of lunatic to actually a

• TimJYoung 10y ago
  Sorry, I should have made it clear that what I posted was pseudo-code, so just assume that = is equivalent to == or whatever in the target language. 1) Yes, my issue was the constant being on the left side. I've seen it done a few times, and I'm sure it's probably just a "I did it that way when I first started and it stuck" or something similar, but it just never looks right to me. I just want to scream "But, you're comparing the variable !!!!". :-) 2) Constants are useful when there are going to be gaps in the values (message dispatch codes), but yeah, I also agree here - enums are always the way to go, if you can do it. Switches are also great, but can be problematic at times due to the way that they aren't always implemented in a consistent manner among various languages with respect to fall-through and breaks.
• onion2k 10y ago
  I can't articulate exactly why, but that should totally be flipped. Should it? If you accidentally use an assignment operator (eg = ) instead of a comparison (eg === )[1] with the constant on the left your code will throw an exception, which is what you want. If you put the variable on the left and accidentally use an assignment then you'll overwrite the variable with the constant value and return true, consequently executing whatever is in the block of code that the comparison is supposed to be checking for. You don't want to do that. That could be really bad. [1] If you use == then you are bad and wrong.
  • MrLeap 10y ago
    Good point. I've been writing a lot of coffeescript recently, and the `is` operator insulates me from that whole situation. re [1] - javascript isn't the only language == isn't bad and wrong everywhere!
    • crpatino 10y ago
      Ok, this explains a lot. What you are seeing is people taking specific C codying styles into other languages. This is a cargo-cult style and probably in detriment of your code base. On the other hand, it makes perfect sense in a C code base. The purpose of this is to transform a semantic error into a syntactic error. In C, both this expressions are legal but semantics is different: if (A == B) //Compare B to A, decide on boolean result if (A = B) //Assign B to A, then cast B's type //into a boolean value (non-zero true, //zero false) and decide on that. In theory, it should be possible to identify every instance of A=B, but then it is hard to tell if it is a typo or the actual intention of the original programmer. If you compound this with the tendency to write complicated code, you find monstrousities like this one: if (!A & B = C == D || E == F = G) I am sure there's a language lawyer that can tell you for sure that the above means. I, on the other hand, can only be sure that this will compile as long as B and F are L-values.
      • boomlinde 10y ago
        Putting constants before variables in comparisons is relevant in Javascript for the same reasons that it is in C. Perhaps even more so, since the browser compiling the code won't have -Wparentheses to lean on
  • johnmaguire2013 10y ago
    Unit testing helps with this.
  • psyc 10y ago
    This 'reason' is as old as C, and it's always seemed to me like tying bells to your shoelaces because it would be bad if you forgot to tie them and tripped. I.e. the 'solution' is orthogonal to the problem. If you can train yourself to put the constant first, you can train yourself to use the right operator. And you can test your code.
    • onion2k 10y ago
      If you can train yourself to put the constant first, you can train yourself to use the right operator. Ideally, of course. But pragmatically mistakes happen. The point is that there's no cost - so why not use an explicit order and the right operator? And you can test your code. A lot of developers don't, or they only test for simple success cases that wouldn't catch this class of bug. It's scary.
      • mattkrause 10y ago
        You also have a tireless automated assistant who can check for this: the compiler. Clang warns about this by default: warning: using the result of an assignment as a condition without parentheses. note: place parentheses around the assignment to silence this warning. note: use '==' to turn this assignment into an equality comparison. " gcc gives you similar warnings with -Wall or -Wparentheses: warning: suggest parentheses around assignment used as truth value [-Wparentheses] Why not stick with the more natural phrasing and let the machine handle the tedious work?
    • crpatino 10y ago
      > If you can train yourself to put the constant first, you can train yourself to use the right operator. Right... that's assuming you work solo. In that case, you might as well be using some higher level language and sidestep the whole issue. Most C programmers out there work in teams, in long lived projects... that means teams with rotation of personnel. This is a fuckup waiting to happen. I get you guys do not like axes, and it is really Ok. But forgive me if I am skeptical of your axe redesigns until the day you actually go out and do a full hour of wood chopping with that fancy bastard sword of yours.
• dualogy 10y ago
  > 3.17 == possiblyPi Seems bad style to me, but also contrived. Whereas > PI == validate(parseFloat(fetchUserInput({ timeout: minutes(1), defaultOnCancel: 0.0 }))) as pseudo-code example seems rather more insta-grokkable to me than flipped. Get my drift? And it's lit==varExpr
  • optimuspaul 10y ago
    I don't agree... but I also generally use languages that don't have equality and assignment operators that are so similar that people are prone to mixing up the two.
    • dualogy 10y ago
      Who has ever mixed up == and =? Might glasses be in order? ;) No danger in languages allowing for FP-style immutables (whether via `readonly` or `const`) luckily