See Also: part 1, part 2, part 3, part 4 and part 5.

Updates:

• 2025-02-19 – “new information has come to light!”

As someone who learned C back in the late 1980s, I am constantly surprised by all the “new” things I learn about this language. Back then, it was a K&R-era compiler, so there were no prototypes, and functions looked like this:

main(argc,argv)
int argc;          /* argc = # of arguments on command line */
char *argv[];      /* argv[1-?] = argurments */
{
    ...stuf...
} 

…and this…

MallocError(wpath)
int wpath;
{
   ShutDown(wpath);
   fputs("\nFATAL ERROR:  Towel was unable to allocate necessary memory to process\n",stderr);
   fputs(  "              this directory.\n",stderr);
   sleep(0);
   exit(0);
}

Today’s article is not about how old I am, but about something I just started doing, and wish I had done long ago.

Yoda would be happy…

When I learned to program BASIC, I learned how to compare a variable:

IF A=42 THEN PRINT "DON'T PANIC!"

When I learned C, the thing I had to get used to was double equals “==” for compare and single equal “=” for assignment:

int a = 42;

if (a == 42)
{
    printf ("Don't Panic!\n");
}

This, of course, leads to a common mistake that I have stumbled on many, many times over the past decades: Sometimes a programmer misses one of those equals:

if (a = 42)
{
    printf ("Don't Panic!\n");
}

This will cause the code to always enter that section and run it, regardless of what you think “a” is set to. Why? Because it is basically saying “if a can be set to 42, then…”

---

Or does it?

Normally, I wait for a follow up to discuss corrections and additional details I learn from the comments, but this one deserves an immediate revision. Aidan Hall left this tidbit:

It’s even worse than what you suggest! Assignment expressions evaluate to the value that was assigned (on the RHS), so this if block wouldn’t run:

if (a = 0) {
puts(“zeroed”);
}

– Aidan Hall

I had mistakenly thought it was testing the result of “can a be assigned” and assuming this would always be true. I did not realize it was the value of the assignment that was used. Wowza. Thanks, Aidan! And now back to the original content…

---

By leaving out that second equal, it now becomes an assignment. It might as well be saying:

if (1)
{
    a = 42;
    printf ("Don't Panic!\n");
}

I have caught this type of thing in code I have worked on at several jobs. And, I’ve caught it in code I wrote as well. Even recently…

But Yoda would be proud. Smarter programmers already figured out that you can write those comparisons backwards, like this:

if (42 == a)
{
    printf ("Don't Panic!\n");
}

The first time I ever saw that was at a former job, and it was code from a team over in India. I thought this was very odd, and wondered if it was some odd convention in that country, similar to how in America we would write “$5” for five dollars, but in Europe it might be “5 €” for five Euros.

Honestly, as backwards as that looks to me, phonetically it makes more sense when you read it ;-)

And don’t get me started on America’s Month/Day/Year and how confusing OS-9’s “backwards” time of Year/Month/Day was… but I quickly adopted that, since you can sort dates that way, but not in the “normal” way.

But I digress…

By reversing these comparisons, you now eliminate the possibility of forgetting an equal. This won’t give an error (but a good compiler might give a warning):

if (a = 42)

…but this cannot be compiled:

if (42 = a)

When I started working on some new code this past weekend, I just decided to start doing things that way. It quickly becomes second nature:

if (NULL != ptr)
{
}

if (false == status)
{
}

But it still looks weird.

Now to fire up that old 1980s compiler and see if that was even possible back then…

Until next time…