A modern programming language that makes developers happier.

kotlinlang

image.png

I ran into a bug in some Kotlin code where `!==` was used for string comparison in a spot where `!=` was really desired. This was particularly nasty since a unit test passed but then failed in production . Looking at the code, the use of `!==` was even harder to notice since I had ligatures turned on. The author of this code had been writing a lot of javascript at the time and was in the mindset of using `!==` leading to the bug.

The code is basically:
```const val SCHEMA_VERSION = "3"

...

// then later in the file

if (originalSchemaVersion !== SCHEMA_VERSION) { 
  //evaluates to false when originalSchemaVersion is "3" (string) and SCHEMA_VERSION is "3" (string) unless they are the same instance (is true in prod, false in unit test (since in the objects happened to be the same instance in the test)
  <http://logger.info|logger.info>("Running post-processing on this....```
I also was surprised to see that when I evaluated the code in the "Evaluate expression" dialog in the debugger, the object id of the SCHEMA_VERSION constant evaluated in the dialog was different than in the running code, as seen in the screenshot.

Two things that came out of this that I'd love feedback on:
1. It seem like it would be nice to have a "likely bug" Inspection that catches `!==`/`===` usage on things like strings since most of the time the user wants `==` /`!=`. For the times when the user really wants `===` /`!==` they can mark the inspection disabled for the line. Does this makes sense as something that IntelliJ should support? I don't see it as an existing feature of IntelliJ/detekt, and I haven't looked yet to see if there is an open youtrack ticket for it.
2. Any ideas why the "Evaluate expression" dialog is showing a different instance for SCHEMA_VERSION than in the running code?


1. Regarding the inspection: It exists for Java. I was surprised to find, that it doesn't exist for Kotlin – so I created <https://youtrack.jetbrains.com/issue/KTIJ-31691/Add-inspection-for-when-strings-are-compared-with|KTIJ-31691>
2. I _guess_ it's because the "evaluate" code snippet is compiled separately so the compiler couldn't know it already had an instance of the constant, while for the unit test it sees the entire thing and does string dedup because it's sure it's the same.