4 ms·

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 s

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 ;)
- thyrsus 10y ago
  I don't get it. A test for (in)equality is commutative unless you're inducing side effects (i++) - and then side effects are going to be the big "cognitive load", regardless of which side of the comparison they occur. Am I dyslexic because (null != foo) is exactly as easy for me to read as (foo != null)?
  - douche 10y ago
    It reads awkwardly for a lot of people, to the point that some call these constructs Yoda Conditionals. I'm quite happy that all the languages I use regularly disallow assignment in ifs, at least.
  - irishsultan 10y ago
    At least in C++ you shouldn't count on the order in which a and b are calculated in a == b, because comparisons are not sequence points. So no, even including side effects testing for (in)equality is commutative.
TimJYoung 10y ago
And there it is - thank you. I knew there had to be a reason, but couldn't quite figure out why and the example in the article (null != variable) was different enough to confuse the situation. I haven't written anything in C in quite a while, and completely forgot about inline assignments. Which brings me to another pet peeve of mine, inline assignments... ;-)

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 ;)
thyrsus 10y ago
I don't get it. A test for (in)equality is commutative unless you're inducing side effects (i++) - and then side effects are going to be the big "cognitive load", regardless of which side of the comparison they occur. Am I dyslexic because (null != foo) is exactly as easy for me to read as (foo != null)?
- douche 10y ago
  It reads awkwardly for a lot of people, to the point that some call these constructs Yoda Conditionals. I'm quite happy that all the languages I use regularly disallow assignment in ifs, at least.
- irishsultan 10y ago
  At least in C++ you shouldn't count on the order in which a and b are calculated in a == b, because comparisons are not sequence points. So no, even including side effects testing for (in)equality is commutative.

TimJYoung 10y ago

And there it is - thank you. I knew there had to be a reason, but couldn't quite figure out why and the example in the article (null != variable) was different enough to confuse the situation. I haven't written anything in C in quite a while, and completely forgot about inline assignments. Which brings me to another pet peeve of mine, inline assignments... ;-)