Star import vs importing each element

I know this is not a kotlin specific question, but I’d still be interested in your opinions.
I personally like to use star imports. It’s just the way I like to code. I don’t really have any good arguments for this. The only one I can think of is that it makes the file shorter (in some cases much shorter, I have seen up to 200 lines of imports in some cases). This is not a problem when using an IDE since I can just fold them down into one line, but it comes in useful every know and then when I use a different editor, view files on github, etc.
The argument I can think of for importing every class, extension function, etc on it’s own, is that it’s easier to find where a class comes from when not using an IDE, but I don’t think that’s that important.

Are there any other arguments? I noticed that the kotlin coding conventions don’t have an opinion on this, but Intellij uses single imports by default (switching to start imports at 5 imports from the same package I think).

Honestly I don’t care, since I am working in the IDE 100%. I cannot even imagine coding Kotlin in a plain editor.

1 Like

agreed, that’s why I’m using star imports, since it’s nicer when I use github or any other git related tools that don’t understand kotlin.

The main reason I have not to use star imports is that they can cause break at a distance.

If you’re using A.SomeClass via a import A.* in a file where you also have a import B.* then updating B to a newer version which introduces B.SomeClass will break your build as you’ll have to fully qualify all your usages of A.SomeClass.

The scenario above is obviously rare but the larger the code base the more likely it becomes.
And, from my experience, you want to remove all possible hurdles to updating dependencies. Adding a new name in a package is always a safe operation, hence you don’t want that to break your build.

4 Likes

That’s a reason I haven’t thought about. But as you say it is probably very rare. That said I can’t remember running into conflicts between libraries more than once in the last idk 5 years of java/kotlin, but still. It might be a problem in big corporate projects where the person responsible for the versions of libraries used can’t easily change this.
But then at my old job we weren’t allowed to use star imports by our coding convention.

If I recall, the view of JetBrains is that it doesn’t matter too much either way, because in most cases the imports are folded up by the IDE and developers don’t see them.

In my experience, it doesn’t matter too much. As mentioned above, star imports have the slight risk of pulling in more than you expect, which can break existing code if classes get added later. But that’s rarely a significant problem in practice. Star imports also make it harder for anyone reading the code outside an IDE to see where each class is coming from.

However, star imports have a slight convenience when writing code that uses multiple classes from the same package, in that you don’t need to keep adding extra imports (or telling your IDE to do so). And the code is slightly shorter (when reading it outside an IDE), which is a good thing when all else is equal.

So there’s not much in it, either way.

As with many of these things, it’s probably more important to be consistent: consistent across a codebase, and consistent with what your colleagues are doing. (You don’t want to find your IDE has changed all the imports and added lots of diffs every time you change a file.)

1 Like

Bingo. Exactly the same problem as in Java.

This happened big time when Java 1.2 came out - they added java.util.List, and nearly everyone before then had

import java.util.*;
import java.awt.*;

and that same nearly everyone’s existing code stopped compiling (as there was now a “List” class in both packages). Nasty… LOTS of code to update. And that was a “simple” case to fix…

I wrote a little article about it here: http://www.javadude.com/posts/20040522-import-on-demand-is-evil/

– Scott

4 Likes

The argument for never using star imports comes when working in a team where someone may not know where a particular class comes from. Without star imports it is explicitly documented at the top of the file so makes it easier to find.

You say it doesn’t matter because of the IDE, but IDEs are not the only place you look at code. I do a lot of looking at code in the repo in github, in PR reviews, and even in git kraken where you don’t have the easy navigation of an IDE.

On the flip side no one would explicitly include every import if it weren’t for IDEs to do the work for you.

So if you are working by yourself you can get away with star imports although I would use intellij’s ability to switch to star import only when you have more than say 5 imports from the same package.

If developing as part of a team or on an open source project (which is technically just a very large team) it is probably better to not use star imports.

2 Likes