11 ms·

I can't up-vote this enough. As someone that started doing development in the late 80's, I find this style of coding to be infuriating. It completely destroys

I can't up-vote this enough. As someone that started doing development in the late 80's, I find this style of coding to be infuriating. It completely destroys the ability to map lines of code directly to function calls without resorting to manual coding rules that require that each .function() be on a separate line, and makes debugging way harder than it needs to be. And, for what purpose ? To avoid a local, temporary variable ? Do these developers think that their code is faster this way, or...what ? It's "write-only" code - good luck to the next guy that has to read it. And, don't get me started on: if <Constant> = <Variable>... :-)

MrLeap 10y ago
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 assign a constant inside of an if's condition. 1. I can't articulate exactly why, but that should totally be flipped. The constant should be on the right side! `if(3.17 == possiblyPi)` would make me seriously question the author's motives. 2. It's personal preference, but in almost every situation I'd prefer to use a switch over an enum than lots of constants.
- 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
- 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
dualogy 10y ago
> And, don't get me started on: if <Constant> = <Variable>... That seems to be quite the pet peeve with many and I quite like the style in certain scenarios: namely the common one where the constant is a simple literal and the variable portion is a longer (no, not excessively long, just.. longer ;) chain of things, a call within a call or some operator etc. It's as if to signal "there is some crunching/intricacy here but look, it's just to check against this simple value here right at the start". Kinda reassuring. Likewise find it quite readable for checking for magic strings / code-monikers (of course to be avoided but sometimes not when dealing with certain input formats etc) and especially when a couple of such in a row are tested..
- noobiemcfoob 10y ago
  I like your example a lot. It's easy to imagine a monstrosity of an equation stretching off to the right, but knowing the solution (or at least a solution) can constrain the knee-jerk reaction of "oh, that looks complicated"
Falling3 10y ago
When learning C in college, I was specifically taught to use CONTSTANT == variable. Accidentally omitting a '=' is common and putting the constant on the left side ensured the compiler would catch the mistake.
- valleyer 10y ago
  if (x = 5) is a default warning in clang (and I think gcc) nowadays.
- kennu 10y ago
  I would argue that by using CONSTANT == variable, you are reducing the cognitive load of the compiler, but increasing the cognitive load of the human reading the code (who has to mentally flip the expression around). I think the original article intended to say the same thing.
  - SomeStupidPoint 10y ago
    Thats just what you're familiar with. I find it perfectly natural to read "if 5 == x:" without having to flip it around. (And it's not about "cognitive load" on the compiler, it's about fail to error not fail to silent success.)
    - closed 10y ago
      Agreed. I think the key here is that consistent exposure over time to patterns reduces cognitive load through "chunking".
  - nurettin 10y ago
    Compilers don't have cognitive loads.
    - adrianN 10y ago
      Ask C++ compilers when they have to chew through Boost ;)
deleted 10y ago
[deleted]

MrLeap 10y ago

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 assign a constant inside of an if's condition. 1. I can't articulate exactly why, but that should totally be flipped. The constant should be on the right side! `if(3.17 == possiblyPi)` would make me seriously question the author's motives. 2. It's personal preference, but in almost every situation I'd prefer to use a switch over an enum than lots of constants.

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
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

dualogy 10y ago

> And, don't get me started on: if <Constant> = <Variable>... That seems to be quite the pet peeve with many and I quite like the style in certain scenarios: namely the common one where the constant is a simple literal and the variable portion is a longer (no, not excessively long, just.. longer ;) chain of things, a call within a call or some operator etc. It's as if to signal "there is some crunching/intricacy here but look, it's just to check against this simple value here right at the start". Kinda reassuring. Likewise find it quite readable for checking for magic strings / code-monikers (of course to be avoided but sometimes not when dealing with certain input formats etc) and especially when a couple of such in a row are tested..

noobiemcfoob 10y ago
I like your example a lot. It's easy to imagine a monstrosity of an equation stretching off to the right, but knowing the solution (or at least a solution) can constrain the knee-jerk reaction of "oh, that looks complicated"

Falling3 10y ago

When learning C in college, I was specifically taught to use CONTSTANT == variable. Accidentally omitting a '=' is common and putting the constant on the left side ensured the compiler would catch the mistake.

valleyer 10y ago
if (x = 5) is a default warning in clang (and I think gcc) nowadays.
kennu 10y ago
I would argue that by using CONSTANT == variable, you are reducing the cognitive load of the compiler, but increasing the cognitive load of the human reading the code (who has to mentally flip the expression around). I think the original article intended to say the same thing.
- SomeStupidPoint 10y ago
  Thats just what you're familiar with. I find it perfectly natural to read "if 5 == x:" without having to flip it around. (And it's not about "cognitive load" on the compiler, it's about fail to error not fail to silent success.)
  - closed 10y ago
    Agreed. I think the key here is that consistent exposure over time to patterns reduces cognitive load through "chunking".
- nurettin 10y ago
  Compilers don't have cognitive loads.
  - adrianN 10y ago
    Ask C++ compilers when they have to chew through Boost ;)

deleted 10y ago

[deleted]