Probably the worst inspection IDEA has to offer :s...

# random

[Marc Knaup]

Probably the worst inspection IDEA has to offer 😅
Esp. bad for people who are new to the language.

[wasyl]

Why?

[Marc Knaup]

Because it completely changes the meaning from exception to simply omitting some code from being executed.

In most cases you want to properly handle unexpected null and not simply skip some code.

It does make sense in some cases, but the “weak warning” here can suggest new developers that using return is always the better option.

[Marc Knaup]

Actually at KotlinConf this year there was one talk that discouraged exactly that approach - ignoring null to avoid the !! 😄

[Alowaniak]

Heh, I thought inspections usually didn't change the functionality of code

[Marc Knaup]

Inspections don’t. But developers relying on them do.

[wasyl]

Ah, I missed that the inspection changes semantics 😕

[Paul Woitaschek]

My most unloved inspection is to replace nested null checks with ? calls

[napperley]

Was expecting the IntelliJ inspection to have the option to replace !! with ?: defaultValue, eg val a = number ?: 0.

[Marc Knaup]

Returning or using a default value both makes sense in some scenarios.
Note that while it’s easy to come up with default values for primitives, it won’t work for most class types.

But there usually is a reason that someone uses !! in the first place, because the value is expected to be non-null.
Treating it as a warning with the suggestion to change it either to ?: return or ?: default will completely change the intention from “expected to be non-null” to “legit to be null so do something else in that case”.

Hence the inspection is almost always misleading.

[Marc Knaup]

@Paul Woitaschek I’m not sure what you mean,. Could you give an example? 🙂

[Marc Knaup]

https://youtrack.jetbrains.com/issue/KT-35644

[cedric]

Yeah it's bad. `!!`will crash immediately while the suggestion will make the code appear to work (and probably crash later).

[napperley]

Using !! is good in Unit testing since if there are null issues you want to pick them up quickly, before they create a larger issue in a program/library.

[bjonnh]

That's the erlang way, crash early, be happy

[cedric]

Or you could use a statically typed language and not crash in the first place

[bjonnh]

Having the compiler bark at you is just a "crash early" 😉

[bjonnh]

Talking about that, there was a great talk at kotlinconf on how to do typing properly (someone from soundcloud IIRC)

[tmg]

Type are awesome but they don't save you from everything.

[tmg]

https://joearms.github.io/index.html#2013-04-01%20Too%20big%20to%20fail