How do you "hold" functions, variables and their values ​​in your head when writing a program, or parsing someone else's code?

Question

Programming

For example, I'm trying to understand a program I didn't write. When I go from top to bottom along the lines of code, the further I disassemble, different values ​​fly out of my head one after another, whether they are functions or variables. Especially the states of their meanings in "current time". It happens that you try to understand nested loops, or conditions, and you just physically cannot track the progress of their work from "a to z", at some point you stupidly forget where you stopped "at the moment".
Am I having memory problems, or is the secret in paper with a pen handy?

Answer 1

1) when it comes to my code, I try to write it in such a way that it would not be necessary to remember all this:
- meaningful names of functions/methods/variables
- locality, everything dumb is taken out into separate functions / methods within which everything is simple and logical, split everything into small, understandable things, this is perhaps the simplest thing you can do
- SOLID
2) if we are talking about someone else's code, a debugger, a leaf and a pen, I draw diagrams, etc., I cry ... If I can, again, I slowly start to put pieces of code into individual functions, etc. if it bothers me and I don’t need to read this code stupidly and figure it out, and then I’ll also have to edit it.

Answer 2

DEBUGGER

Answer 3

I usually try not to write one long code, just for the sake of something like that. I deliberately break it down into functions, pages.

Answer 4

Problem decomposition only !
Without competent decomposition, the onset of shit code in a project is inevitable over time.

Answer 5

The most important developer tool is paper and a pen. Code decomposition is the next major tool. The debugger is near the end of the list. If you look at your own code and don't understand what's going on, then the code is too big or too complicated or there are no comments. Comments generally play a very important role, on the one hand, the code itself says (at least it should say) WHAT the code does, and the comment says WHY it is needed. You can also use contract programming (assert for example) in order to make it more clear what is happening. Imperative programming and OOP tend to spaghetti code especially at the prototyping stage. Functional programming often helps to solve some of the problems (sometimes it adds new ones).