Just style or does it actually make a difference t...
# getting-started
m
Just style or does it actually make a difference to
import <somelibrary>.*
as opposed to specifying the exact element(s) of the library? Presumably the only processing implication is during build, but is the value of the precision in self documentation, and is it worth it?
s
I think it’s mostly style and only seldom real name clashes, but you should in general comply with the sensible defaults Detekt is checking for.
Regarding style one of the great thing we have with Kotlin is an official code style document. Java is missing such a thing as Sun never made one and left us with different code style proposals from different companies and nothing really all developers could agree on.
r
thank you color 2
m
I love standards, except where I don't agree 😎
😅 3
s
Why I didn’t find this document after looking for it several times in the past 20 years as a Java developer is beyond me. 🙈 Thank you a lot.
b
Do detekt (and ktlint) enforce the official code style for Kotlin?
👌 1
m
@Stefan Oltmann, on that (those) detekt page(s) you referred to, what is "debt"? I assume it's something to do with extra processing time, but "5 min"??? (I did search on the site, but of course extra page has "debt" on it 😞)
e
Technical debt. An estimate of how much time it would take for someone to fix it
"Debt describes the estimated amount of work needed to fix a given issue."
g
I’m certainly not an expert in kotlinc, but it’s quite unlikely that wildcard imports will cause any issues apart from hiding the details about the API you’re using. That said, when using any linter, the first thing I allow as ‘OK’ is wildcard imports.
👍 1
s
If you have two packages imported that happen to have classes of the same name you need to specify explicitly which you want. It’s not a big thing. I disallow wildcard imports on my projects because I like the explicit statement which classes I want. The block is usually automatically collapsed, so it doesn’t matter how many lines there are.