<https://medium.com/@pere_44849/rebutting-the-adva...

# feed

[Pere Casafont]

https://medium.com/@pere_44849/rebutting-the-advantages-of-java-over-kotlin-1f02f7b5789b

[Matej Drobnič]

IMO some points in the troll article were valid. For me, Kotlin is actually much harder to follow than Java when reading code outside IDE (for example when viewing code directly on Github).

However, most of the time I spend writing code in the IDE where benefits outweigh these drawbacks.

[Pere Casafont]

My point is exactly that: there are cases in which it is uncomfortable, but it has a reason to be like that and it is worth it given all the additional features coming with the language

[Mike]

@Matej Drobnič any ideas of what makes it much harder for you to read outside an ide?

Or what makes it easier in the IDE? I find it can be a hit tougher at times, but suspect that if it's a lot tougher, then the code is being too clever. Favouring clever over readable.

What feature of the IDE makes it easier for you? Does full syntax highlighting make thatuch difference? Type hints? Instant access to docs?

[Matej Drobnič]

It's mostly jumping between code / digging further into whatever code you are reading:

1. Classes can be defined anywhere. With Java I can just use "Find File" feature of the Github and enter class name, but with Kotlin, class can be defined in file with totally different name. With IDE that is of course non-issue (Go to declaration feature).

2. Extension methods can be defined anywhere. With wildcard imports (which most of the projects, including Jetbrains ones seems to use), it is pretty much impossible to find source of the extension methods without using IDE's Find implementation button. To some extend I can find methods with Github's full text search, but it is cumbersome.

[Matej Drobnič]

For example, I was digging through coroutines source lately. Suddenly I stumbled onto method that was not declared in the file (or the class). All imports were jus import kotlinx.coroutines.*, so I had no idea where that method is.

But even without wildcard imports, many extension methods can be stuffed together into single pacakge. For example let's say that I see a launch method in code. Imports say kotlinx.coroutines.launch. Unfortunatelly, it appears that pretty much every single method in coroutines is stuffed into that package. So that does not narrow down my search scope at all.

[Pere Casafont]

My 2 cents: clone and import it to your IDE, the 2 minutes it'll take will be less than the waste of time navigating through GH; the advice also applies for java projects.

[Mike]

All very good points thank you. I push for teams to not use wildcard.imports and enforce with Detekt just to reduce the 'where did that extension come from' issues. And generally, lean toward Java approach of one class/file. Exceptions will be lots of data classes for model. A few others, but generally.

I think it's unfortunate many rely on wildcard imports. Ide shrinks it. Compiler doesn't care. So I like readability improvement.

I only.look at code in github et al for code review. And if I find I'm having to explore too much, I'll also clone it locally and import into ide.

Applies about the same to Java and kotlin and any other language.

[Matej Drobnič]

yea, cloning is of course the best, but it takes a while. If I need to check something quickly, I do it on github.

[Matej Drobnič]

that is also why I agree with ktlint's controversial decieion to enforce no wildcarr imports

[Mike]

And then Roman has to give us a good reason for using wildcard imports...

https://medium.com/@elizarov/extension-oriented-design-13f4f27deaee