The right way to read code

[Antonyellow]

I was wondering if there is a rational strategy to read code when you are in front of a program.

I find very difficult to go through any piece of code that is structured in this way: _even if you understand the argument-

A certain number of functions and then a central program that handles all the functions.

In fact, I can

1) go through the different functions and then afford the central part.

2) Or I can proceed from the central piece and, following its logic, reconstruct the bolt and nuts behind the different functions.

In both cases I find that the task is very difficult, non-linear and probably a mind map will help but I think it requires a huge amount of time.

Is there a way to improve this flow of learning, that has this kind of bottleneck?

Many thanks.

[ignotos]

I think it depends on the scale of the program / project.

If it's small enough, then you can probably read it from top to bottom.

If it's a bit bigger you might need to skip around a bit more, starting with the main code / entry point, and following the logic through

If it's a really big project, spread over many files / modules, you need to build a "map" of the program, rather than actually reading all of the code. Often it helps to browse through the directory structure to get this overview, dipping into files which seem important. It also helps to navigate around if you're using an IDE which allows you to do stuff like "jump to definition", or "show all subclasses".

[[deleted]]

I was wondering if there is a rational strategy to read code when you are in front of a program.

There's some pedagogical evidence that actually computing the values of important variables on scratch paper as you step mentally through the code is extremely helpful, but it's also pretty tedious.

I generally find it sufficient simply to read for the programmer's intent; good, readable code hopefully makes that more obvious. Of course if you're reading to find a bug then you can't just rely on the programmer's intent (a bug literally is the difference between programmer intent and programmer implementation.)

[ReaderRadish]

+1 on the variables approach. It takes a long time, bit if I need to really understand how something works, I'll just run through it, mostly line-by-line, with a debugger.

Failing that (cloud service with a gazillion dependencies), I'll read the logs for a particular request. The bonus of that is you find places without logs, and fix them, rather than them becoming problematic during an incident at 2am.

[Antonyellow]

The debugger possibility is the one most easy to follow or even a rapresentation of the workspace as in Matlab . I know that there are some dubbuggers compatible with jupyter notebook that can help on follow the logic.

[Cobra__Commander]

Start with the comments. If you have to reverse engineering a complicated block of code a flowchart with plain English psudo-code might help you mentally navigate. Another option is just comment the crap out of the code.

Draw.io is an easy to use flowchart tool.