Hi everyone. Seb here. Welcome back! Today’s episode of “Kotlin Standard Library
Safari” is going to be a bit different. Generally, in this show, I want
to highlight things in the Kotlin standard library that you’re going
to find interesting and useful. But while I was writing the script for a few
episodes, I realized something critical. What’s really at the center of all
of this is exploration – finding out stuff about the APIs that
you may not have known before. So, instead of going straight into the next topic,
and look at the next set of standard library APIs, we’re going to take a bit of a different
route today! Instead, I want to give you some handy tools to help you explore things on your
own – first and foremost the standard library, but in fact just Kotlin code in general. It makes sense to me to address this
sooner rather than later. You know, so that while you’re waiting on the next
episode of this show, you’re already well equipped to discover some of the goodies in
the code you’re working with on your own. The beautiful thing about working with Kotlin
is that with IntelliJ IDEA and Android Studio, we have some powerful companions at our side that
help us in every step of the development process. So, let me share with all of you how I read and
try to understand Kotlin code that I encounter and modify. I’m working with IntelliJ IDEA
here, but the same things should apply for Android Studio just as well – and when I talk
about keyboard shortcuts, I’m going to mention the macOS keybindings, but you’re going to see
Windows and Linux keybinds on screen as well. Now whenever you see me put code on the screen,
you might have noticed that there are these little grey bobbles wherever variable names
or types appear. These are called inlay hints, and honestly, I don’t want to
read code without them anymore. We enable those under Editor > Inlay Hints >
Kotlin. I personally can’t get enough of them, so I have all of them enabled, but
if you’re feeling overwhelmed with the amount of info on the screen, you
have some fine-grained control here. There are a number of situations where I
especially appreciate inlay hints. For example, when I’m chaining a bunch of operations, they
give me a quick sanity check whether I am creating the correct type at the end. They’re
also awesome whenever you encounter lambdas, especially lambdas with receivers, because
they give you information about variables that are implicitly in scope, or which
receiver your lambda actually provides. Especially if we are working in a project that
makes heavy use of Kotlin’s DSL functionality, these hints can help demystify some of these APIs, and just generally help gain even
more insights into how the code works. Oh, and as a little hint – if we
are using the Gradle Kotlin DSL (so if our build file ends in .kts),
these inlay hints also work here! I have to admit, I tried to actively avoid
touching Gradle for a long time myself, but I’d say that the Kotlin Gradle
DSL together with these inlay hints are one of those features that have helped me
understand how the Kotlin DSL for Gradle works, what functions are available
in what scope, and so on. So yeah, that was my little ad
for the Inlay Hints feature. If you try it yourself, maybe you’ll
fall in love just like I did. :) Now I actually want to return to something
a bit more basic, but that I’m still seeing people miss out on. Code completion is definitely
a common way in IntelliJ IDEA or Android Studio to discover an API, we all know the drill – we put
a dot behind a symbol, and get some suggestions of what we might want to call. But what about
situations where it doesn’t pop up naturally? Those exist as well! For example, when I’m
inside a lambda such as this builder function! Now first of all, notice how the inlay hint
actually gives me this nice information, that I have an implicit `this` in the scope here, and,
of course, I could use this information to type `this`, and then a dot. But that completion
really isn’t the most elegant way – after all, I don’t even need to write `this` here, and
I probably don’t want to keep the `this` in the resulting code, either. That’s like
the whole point of it being implicit! Well, how do we get completion,
then? The answer is real simple: we can actually just press press
control-space to manually invoke completion based on our current scope.
And this works practically everywhere! So in the example of this builder
block, it shows us all the functions we can access in this scope. And if we’re
returning to an unfinished statement, we can also use control space here. Super
versatile, I use it every day. If I actually check my productivity guide in IntelliJ IDEA, it says
here I invoked basic code completion 2400 times over the last four months or so. And I’m not
writing code full-time! You get the idea. Okay, let’s say completion found
us a function that looks promising judging its name. When we first type
out a function with parentheses, IDEA gives us a little hint bubble
that tells us the parameters that the function accepts. But that popup only appears
the first time we put down the function. But, because we’re dealing with
an API that we’re just exploring, we might not immediately fill in the parameters.
We go back and forth in our code. And when we return to our function, we would appreciate a
quick reminder of the parameters that it accepts. Well, this is once again a simple
trick: If we press Command-P, we can magically summon that popup
again that we’ve seen before. And, if we look at a statement
that has been written previously, we can see that even here it might
make sense to hit Command-P again. Because the popup also shows things
like default parameters and overloads. This once again helps us discover new
functionality while typing out our own code. In this example, maybe we find ourselves in
a situation where we want to compare two strings, but weren’t sure if or how the function accepts an extra parameter to ignore the
upper- and lowercasing of the text. Oh, and we actually talked about ignoreCase
and friends in the previous episode of the Standard Library Safari. So go check that
one out as well if you haven’t seen it yet. And while we’re already inspecting the parameters
of a function, we can go one step further. We can pop open a quick-documentation! If we hit F1,
IntelliJ IDEA is gonna show us a little text blurb explaining what a method is supposed to do.
And here’s a nifty little trick: We can actually pin this window to the side of our IDE,
and we can click the little cogwheel that says “auto-update from source”. And
now, if I click around in the code, I always get up-to-date information on the side
of my IDE about the function I currently use. ...the Kotlin Online Docs
And now I’ve already brought up documentation, it’s also a great moment
to plug the official Kotlinlang.org website and the docs you can find there. Because,
really, let’s not kid ourselves here. What I’m here isn’t foundational research. The
Kotlin standard library is well-documented. Without a doubt, if you go to the docs on
Kotlinlang.org, and take some time to browse through some subjects or pages you haven’t
read beforehand, you might find yourself learning about a concept or language construct
that will come in handy the next time you are creating new code with Kotlin, or refactoring
some code you wrote a few months back. But enough about that. You know the docs exist. I
know you know the docs exist. Back to the IDE. And let’s talk a bit more about navigating code! Now, if you’re only taking one shortcut away
from this, let it be Command-Click – or, as known by its formal title, “Go to declaration or
usages”. As that name might suggest, it’s actually a two-way shortcut. When we click on the usage
of a symbol – a variable, a place where we’re constructing a new object, invoking a function
or where we’re implementing an interface – this shortcut is going to send us straight to
the definition of what we just clicked. And vice-versa, when we click on
a symbol declaration – so a place where we’re declaring a variable,
an interface, a class or a function, this is going to give us a list of all places
in our project where that symbol is being used. In an average Kotlin program, a lot
of things are Command-clickable. And Command-click is an easy way to
reveal interesting information about your own code and the code you depend
on. You can really go wild with it. For symbols that we defined ourselves, like
variables, this is just a really neat way to navigate our own code base. But of course, we
can also click into library functions, both from the standard library or from any third-party
library that we have added to our project. I find stepping into a library useful for
a bunch of reasons – we can look at the code we’re calling, learn something from its
implementation and its structure, and we can immerse ourselves even deeper. We can kind of
swing from implementation to implementation. Anyway, looking at where we’ve ended up, as
is convention with both Kotlin and Java files, once again, we have the docs
right next to the implementation. IntelliJ IDEA and Android Studio actually
have this nifty little feature called “Rendered API Docs” which makes it
a bit more comfortable to read the docs which are included with the code. I
personally like it because it also gives us an even stronger contrast of
what is docs and what is code. Now let’s say we ended up navigating to a file
that we find particularly interesting. You know, one where there’s a lot of implementations, a lot
of juicy code to look at. We can of course scroll up and down, take a look at some symbols, read
about them and so on. But IDEA once again can help us with a more structured browsing approach,
which might help us discover interesting parts of the file quicker. There’s the “structure”
toolwindow, which we can find via View - Tool Windows - Structure. And we can use this as
another navigation helper. You know, to give us an overview of everything that’s in the file,
conveniently located next to the actual code. And, last but not least, if you just can’t
find what you’re looking for by navigating around this way, you can always go back to the
good old search function. We can reach that with “Find in Files”, reachable via Command-Shift-F.
And here’s a little trick – by default, this function only searches our own code, not
the code of our dependencies. But if we hit Scope and select “Projects and Libraries”, now
we’re also searching in those files as well. And there’s also the so-called structural search,
which is a bit of a specialized tool when it comes to scouting out code. It allows us to find
constructs matching a specific schema, for example finding functions that have exactly one
parameter. You might not use this one as often. But it’s always good to have heard about the
fact that it exists – you never know when that knowledge might come in handy, and then you
can look into the topic a bit more deeply. Alright, as I said, a little bit of a different
episode today. I promise you – next time we’re back with tackling more topics related
directly to the Kotlin standard library. Hope you enjoyed this one nonetheless,
learned something new. If you have some must-have settings, shortcuts, or whatever,
feel free to share them in the comments. And you know the drill, to stay
up-to-date with all things Kotlin, subscribe button, notification bell, yada yada. Aaaaanyway, next time you touch Kotlin code, try
using some of the new things you’ve learned today. And maybe try and burn these three shortcuts
into your memory and use them rigorously: Command-Click – For jumping around in your
code, finding declarations and usage sites. Command-P – For showing the nifty
little parameter hint bubble Control-Space – For completion,
anywhere and anytime. Of course, there are tons of other productivity
shortcuts in your Kotlin IDE. If you’re interested in more of them, check out the linked video
which covers the top 15 IntelliJ IDEA shortcuts. Or grab yourself a virtual version of this
flyer, which has an overview of the most-used shortcuts using the keymap of your
choice – link in the description. And, just go ahead and try integrating
your new knowledge when you work with Kotlin code the next time. In fact, you
can do that right now – because I am off, and I hope you’ll go and
explore some more Kotlin. See you in the next one!
