I think there are a lot of approaches, and I haven't started on this one yet, but here's my approach, roughly:
- clone it so I can read the code in emacs, and use cscope or similar tools on it
- try to figure out the build system and the directory structure: how is the main program built? are there libraries or tools that are also built? where do their sources live? (so, here, I'd start with source/doom.make and look at the things it references)
- if my primary interest is the main program, I would then try to track down main() and jump through the functions that look interesting with ctags or similar code navigation tools;
- usually it makes sense to jump back and forth to the header files that are being referenced, not only to understand what the types and globals are, but also because they tend to reveal information about how the code is organized.
I usually focus on an area I'm especially curious about if I'm not trying to understand the whole program. For example, in games like this, I'll try to find assembly files or places with inline assembler, because it's usually interesting to see what the developer felt was performance-critical or hard to achieve from C. Then I'd find the functions that call those assembly routines and read them, et cetera.
Taking notes can help, like sketching the module structure or the major data structures on a whiteboard and trying to fill out how they interact. These days I use org-mode for taking notes about code I'm reading, because it makes it very convenient to capture links to specific sections of code (or specific commits, with org-magit) and make notes about them.
If I really have to understand it, I try to get it to build, add tests to the codebase, and maybe try adding a specific feature. But that would apply more to something like the Doom codebases that still build on modern platforms rather than a retro artifact like this.
- clone it so I can read the code in emacs, and use cscope or similar tools on it
- try to figure out the build system and the directory structure: how is the main program built? are there libraries or tools that are also built? where do their sources live? (so, here, I'd start with source/doom.make and look at the things it references)
- if my primary interest is the main program, I would then try to track down main() and jump through the functions that look interesting with ctags or similar code navigation tools;
- usually it makes sense to jump back and forth to the header files that are being referenced, not only to understand what the types and globals are, but also because they tend to reveal information about how the code is organized.
I usually focus on an area I'm especially curious about if I'm not trying to understand the whole program. For example, in games like this, I'll try to find assembly files or places with inline assembler, because it's usually interesting to see what the developer felt was performance-critical or hard to achieve from C. Then I'd find the functions that call those assembly routines and read them, et cetera.
Taking notes can help, like sketching the module structure or the major data structures on a whiteboard and trying to fill out how they interact. These days I use org-mode for taking notes about code I'm reading, because it makes it very convenient to capture links to specific sections of code (or specific commits, with org-magit) and make notes about them.
If I really have to understand it, I try to get it to build, add tests to the codebase, and maybe try adding a specific feature. But that would apply more to something like the Doom codebases that still build on modern platforms rather than a retro artifact like this.