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).
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.
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.)
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…
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.
I am a beginner here but I have a related question. Suppose I am writing an app which uses JetPack compose, and I want to ensure I don’t use a class name which conflicts with JetPack compose, wouldn’t it be safer to import androids.compose.* and then I’ll avoid any conflict locally?
This is minor, but * imports slow down compile times a bit. The compiler has a bit more work to do as it has search where in all your * imports your references are pointing to and resolve the full names itself, so there is a little compile time overhead introduced.
In one of my big projects where I was investigating how to speed up compile times, I compared always using wildcard * imports vs never using them, and found a 2-3% slower time when always using them.
Also, the IDE usually jumps to the right place in the file to look at. If I am scrolling up to see the imports, the folding is of zero use to me. Its one of the first things I disable.