Nagging compiler warnings

[wulf0r]

Hello everyone,

I love Kotlin and I use it extensively. I have many thousands of lines of it in everyday use and I am generally very happy with it.

Unfortunately I have to complain a bit now. I feel like the compiler is mothering me too much. I could be wrong and I am open to changing my mind but the way I see it, there are four issues compounding that make it so annoying for me.

Number one: There are lots and lots of warnings, many more than in Java. When I compile my project I get pages and pages of warnings even-though it’s a good project that works well. So the signal to noise here is not great

Number two: Compiler thinks it knows better when it doesn’t. Take this code:

The warning for ‘driver’ is there because it “could be private”. No, Compiler, it could not be privat because this is a library and the code that uses that library sometimes wants to access driver.

The warning for ‘protected’ is also because it “could be private”. This really infuriating because, DUDE, I told you this is an open class. I also told out that it should be ‘protected’. Do you really think you know better than the programmer that literally typed out the visibility modifier?

In the same file I get “unused” warnings because, well, it’s still a library.

Number three: apparently Intellij removed the feature where I can add the appropriate @Suppress annotation with one click of the mouse
EDIT: This is my bad, the option is there and I just didn’t know where, for whatever reason. This make the whole problem tractable and therefore not an issue for me anymore

Number four: it’s too hard to find the proper pattern for @Suppress given the large number of warnings. When I google it I find “tips” that I should look them up in some plugin source file. Please, guys, this is not okay.

Thanks for reading and I hope you take the feedback in the way it is intended which is that I love Kotlin but hate squiggly lines that I can’t solve…

[gidds]

In this particular case, one factor behind the warnings is probably that you’re calling an overrideable method from the constructor, which is a serious code smell — in fact, authorities like Joshua Bloch in Effective Java expressly forbid it.

The problem is that that code runs while the instance isn’t fully initialised, and in particular before the subclass constructor(s) have run. So any subclass fields will be uninitialised (holding null/0/false), along with any other state or set-up that it’s expecting. Of course, subclasses can be written to handle that situation, but that’s tricky to get right even if you are aware of the problem (which is quite subtle, and even more so if sub-subclasses are involved, and/or the overriding method calls other methods).

I’m fairly sure I’ve seen IntelliJ show a warning about this exact issue; I expect you’re not seeing it only because it’s hidden by the other warnings.

[gidds]

And to comment on the more general question here: yes, Kotlin’s warnings do occasionally go slightly too far – but in my experience the vast majority of them are helpful.

One of JetBrains’ explicit goals for Kotlin is to spot more errors at compile-time; and its more expressive type system, strict typing, and other features do indeed make compile-time errors and warnings from a host of situations that would be run-time errors or bugs in many other languages.

Yes, there are a few annoyances, but they often tend to be either from doing inherently unsafe things (working with dodgy Java code, for example), or deliberately taking unsafe shortcuts in your code — and in both cases the warnings are justified.

A compiler warning is like a code smell: it doesn’t necessarily mean you are doing something wrong, but it’s a strong indication that you may well be, or at least that there might be a better alternative.

[broot]

Regarding @Suppress: I’m not sure which feature of IntelliJ do you mean, but you can place a cursor at the warning, click on a light bulb / alt+enter and there you have an option to either fix the warning automatically or add a proper @Suppress.

[Eliote]

Write tests/examples for that and this warnings will be gone

[mice777]

IDEA has Settings, there is Inspections tab, and here you can enable or disable as many warnings (or even errors) as you wish.
You can also disable warning type from quick fix menu, and possibly enable it back later.

Some warning pairs even fight against each other, for example in Java you can get warning for using final keyword, and another warning for omitting it.

So some warnings are there to enforce some code style, and don’t really mean a mistake.

Anyway, with your enabled warnings, you should aim to keep your code without any of them in code, so that you don’t miss real problem when it’s there.

[wulf0r]

@gidds

In this particular case, one factor behind the warnings is probably that you’re calling an overrideable method from the constructor, which is a serious code smell — in fact, authorities like Joshua Bloch in Effective Java expressly forbid it.

No, that’s not what the warning says. Like I said, it says it should be private because it’s not overwritten anywhere.

@gidds

A compiler warning is like a code smell: it doesn’t necessarily mean you are doing something wrong, but it’s a strong indication that you may well be, or at least that there might be a better alternative.

I never said anything against that. I think the same way. I want to take care of the compiler warnings. That’s why I want good support in handling the warnings and the warnings themselves to be relevant in the current context.

@broot

Regarding @Suppress : I’m not sure which feature of IntelliJ do you mean, but you can place a cursor at the warning, click on a light bulb / alt+enter and there you have an option to either fix the warning automatically or add a proper @Suppress .

Like I wrote, this is not an option in the quick fixes anymore. I have a gradle / kotlin MPP project in Intellij Ultimate 2021.2.3

@Eliote

Write tests/examples for that and this warnings will be gone

Yes, yes I complain about Kotlin compiler being to paternalistic and get told to write more tests. This is exactly my kind of humor

Joking aside, yes all projects could use more tests but I am never going to write tests that make sure that sub-classing “works”.

@mice777

You can also disable warning type from quick fix menu, and possibly enable it back later.

This is also not an option available to me:

@mice777

IDEA has Settings, there is Inspections tab, and here you can enable or disable as many warnings (or even errors) as you wish.

I don’t want to disable these warnings for all my projects. That’s why I think there should be comfortable ways to suppress warnings at the file, module and project level.

@mice777

So some warnings are there to enforce some code style, and don’t really mean a mistake.

Yes, exactly. Code style warnings and functional warnings should be strictly separated and the former maybe even opt-in. The way it is now it would be a quite a task to separate out the opinions about style in the Intellij settings without losing the important warnings.

[broot]

@wulf0r

Like I wrote, this is not an option in the quick fixes anymore. I have a gradle / kotlin MPP project in Intellij Ultimate 2021.2.3

Hmm, that’s weird, it works for me in IntelliJ 2021.3 CE. I don’t think it ever didn’t work.

[wulf0r]

@broot

Hmm, that’s weird, it works for me in IntelliJ 2021.3 CE. I don’t think it ever didn’t work.

The person seems to be having the same issue:
https://youtrack.jetbrains.com/issue/KTIJ-11626

No answer from JB though.

[clovisai]

In my projects I generally don’t have any warnings other than experimental API usage.

[clovisai]

Press the right arrow key in that window, does it really not open?

[wulf0r]

wow thanks, that’s the fix. I thought that option would just make it private. Jesus, well in that case, never mind and thanks again.

[clovisai]

Keep in mind though that warnings are almost always there for a very good reason, and it’s most likely not a good idea to ignore them.

What I often do is to locally ignore a warning when I know it’s wrong (InappropriateBlockingCall when I know it’s in a Dispatchers.IO) and add a comment explaining why so any reviewer can check whether I was write to ignore it or not.