DEV Community

loading...
Cover image for Why you should write constants on the LHS for comparisons?

Why you should write constants on the LHS for comparisons?

Manish
A fellow programmer for over 2 decades - discussing better code, system design, and life as a developer.
・2 min read

I picked up this practice some 20+ years ago in my first job. It was part of the commandments for us newbie programmers back then - we mostly coded in C/C++ those days. We have come a long way since, but I'd argue that this practice could help you save from a blunder some day.

Let me just quote the commandment here -

Thou shall always put the literals/constants on the LHS and variable on the RHS in the if condition for equality!

Code samples:

if(true == deleteAll){
   // delete all records
}

if(0 == quantity){
   // report not available
}
Enter fullscreen mode Exit fullscreen mode

The rationale here is simple – occasionally we programmers, lost in our efforts to solve the complex problems of universe, end up using a single assignment operator = instead of the comparison operator == unknowingly. In case of the languages where if condition does not only accept a boolean (like C, C++), this could result in unintentional assignment instead of comparison. Moreover, your compiler won’t be able to catch it for these languages (most IDEs these days warn about this though), or it will go unnoticed in scripts like JavaScript. However, when you use literal/constant on the LHS, even an accidental, unintentional assignment is not possible. i.e. you simply cannot have this, compiler will flag an error –

if(0 = quantity){
   // report not available
}
Enter fullscreen mode Exit fullscreen mode

But the compiler, or your IDE might not flag an error for this -

if(quantity = 0){
   // report not available
}
Enter fullscreen mode Exit fullscreen mode

..and that’s exactly the point. We let the compiler do the work of finding such bugs instead of realizing it at the runtime, and then eventually spending hours debugging and tracking down one small unintentional assignment, which should have been an equality comparison in the first place.

This approach still makes sense in 2021 including languages like Java, Kotlin (only boolean in if condition) etc. for the following reasons -

  1. Consider boolean comparison itself in Java, what would happen here (ignoring compiler warning for assignment, among tons of other deprecation warnings) if the following code is unintentionally added?
if(deleteAll = true){
    //delete everything?
}
Enter fullscreen mode Exit fullscreen mode

On the other hand, when you write code like this, the compiler would be able to help you, right? 😥

if(true = deleteAll){
    //delete everything?
}
Enter fullscreen mode Exit fullscreen mode
  1. More importantly, you seldom code in a single language as you grow as a software developer. There are times when you need to come up with a small snippet of JavaScript code (well, JS is ubiquitous - ain't disappearing for another two decades or more). All these things would be still valid there.

It is not about any one particular language/technology, it is more about developing better coding practices. These practices help us in the long run, and make us better programmers. 😃

Discussion (0)