When editing, you might notice that there are different colored bars on the right-hand side. If you hover over these small bars, you will be able to see the warning, error, or information in question. This is what PyCharm calls lens mode.

This is really quite useful when you want to take a quick look at the code. You can also see that lens mode will show you all the messages that the colored horizontal bars mean. In this case, you can see that by placing the mouse on the dark yellow bar, we can see the message that it is trying to convey. This can give you a quick bird's-eye view of your code. But, usually, when I want to see what a particular function does, I use Quick Documentation or Quick Definition.

The Diagrams option can also give you a great view of your code; you can simply go to any class and choose to see its inheritance diagram:

This popup will show you a quick representation:

This is great if you want a quick look, and you can also choose to take a look at the variables and methods of the classes:

However, this can get a bit too much to see in the popup comfortably, so it's better to just look at it in a tab of its own. So, using Show Diagram… can instead provide a much better way of navigating large class structures easily:

The best thing is that you can easily navigate to the source as well. These tools have helped me immensely when trying to understand open source libraries such as requests and httpie.

Method hierarchies can be very useful in trying to determine what other methods are being called to be a method as well as what methods call a particular method. If that's a mouthful, let me demonstrate with an example:

# encoding=utf8
import time


def say_doing_something():
    time.sleep(1)
    print("We are doing something")


def say_we_did_something():
    print("We did something")


def do_something(a):
    say_doing_something()
    _ret = a + 1
    say_we_did_something()
    return _ret


if __name__ == '__main__':
    print(do_something(10))

In the preceding example, there are three simple methods. When we call do_something, we call say_doing_something, which calls time.sleep. After say_doing_something is called, add 1 to the initial argument, a. Then, we call say_we_did_something. We finally return _ret. This is an improvised decorator; there are of course far more elegant ways of writing the preceding code, but bear with me. If we now jump into PyCharm, and ask to get all the called methods in do_something, we not only get that, but also the methods that say_doing_something calls, by looking at the Callee Methods Hierarchy. First, we must move our cursor over do_something and then invoke Call Hierarchy. Once this is done, we should see a new panel with the call hierarchy of do_something.

If we now place the cursor on say_doing_something and invoke Call Hierarchy, we again get the same panel; this time we can take a look at the Caller Methods Hierarchy.

We can see that do_something calls say_doing_something. Unfortunately, however, this static analysis does not extend to real decorators. For example, take a look at the following code:

# encoding=utf-8
from functools import wraps

import time


def sleep_for_a_second():
    time.sleep(1)


def tell_all(func):
    @wraps(func)
    def wrapper(*args, **kwargs):
        print("we are doing something")
        sleep_for_a_second()
        out = func(*args, **kwargs)
        print("We did something")
        return out

    return wrapper


@tell_all
def do_something(a):
    return a + 1


if __name__ == '__main__':
    print(do_something(10))

If we place the cursor on do_something, we will not see test_all as the caller or the callee. However, if we place the cursor on tell_all, we can see that do_something is listed as a caller.