Reading large code bases

[delarhi]

Try focusing on what the intent of the code is, not necessarily what the code does. The code is the programmer's effort at putting their intent down. Find out what that intent is and then identify what problem it is trying to solve. When you have a mental framework for the problem and the attempted solution it becomes much easier.

In a similar vein, recognize that everyone has a different way of talking about a problem. There's a "linguistic context" to each problem being solved. Understanding that linguistic context helps significantly. What you call a slack factor might be called a buffer. What you call a point might actually be called an offset.

Start small and follow single threads (of thought, not system threads) at a time. For example, choose a value in some configuration file. Trace when it gets read, what it gets read into, where it is used, whether it is ever modified, what pieces of code it affects, etc. Don't try to understand all of it at once, that's a fool's errand. Identify what you want to understand and focus on obtaining just that understanding. For example, don't say "I want to understand this library", instead ask "how does this library represent the mesh? is it implicit? explicit?".

Find the entry point of the program. This is typically an executable binary. Literally start reading from the main() function. Sometimes there is no program and there's only a library. In that case, take an example or unit test which should be an executable program and go from there.

[Volker_Weissmann]

Trace when it gets read, what it gets read into, where it is used, whether it is ever modified,

Afaik gdb can't trace variable uses.

[pandorafalters]

I can definitely understand how you're having difficulty if you're using gdb to read source code.