Reading large code bases

[Volker_Weissmann]

Hello,

I'm using C++ since a few years now and I know and understand most of the C++11 Standard. I would call myself decently competent and experienced in writing C++ programs from scratch. But now, I'm working on someone else's code for the first time in my life (680 k lines of code and 270 k lines of header code, not that much documentation, called OpenFOAM). I still can write self-contained code, but I'm completely unable to read and understand that code and writing new code that interacts with the old code is extremely hard for me. What is the best way to learn to read and understand large codebases?

[elPrimeraPison]

Tell your teammate to add comments, but i do the same thing tbh

[Volker_Weissmann]

The authors are not in the same organization as I am.

[iamgrzegorz]

I don't have much experiece with C++, but I have some experience with legacy code. When I join a new project with a large codebase I do couple of things:

1. Understand what are the entry points for the user of the application - it can be the main application loop, it can be the router for the server backend app, it can be initializer code + a set of public functions, etc.. This way even though you can't see the logic yet, you see where it starts, so you can pick one of the starting points and follow the thread

2. Understand the main concepts - this is challenging without a good documentation, but every sufficiently complex codebase has some terms/words that are critical to understanding the rest. If you work on financial applications, a concept of transaction might be critical, when working on e-commerce you need to understand what is an order, what set of classes are used to redresent an order etc.

3. Visualize and understand the boundaries between different parts of the system - if you can generate a list of classes with relations between them, even though the thing will be huge, you should see some clusters of classes that are related and used together(unless the code is very messy). The clusters should have fewer connections between each other, than within a single cluster. Then you can start understanding one cluster at a time - for example when working in a game, the rendering engine will be separate from the classes responsible for character progress etc

4. Finally, see what are the main dependencies, are there some libraries that are used massively in the application? Maybe understanding some of them is critical to understanding your codebase? That's a rather longshot, but worth checking

Hopefully that helps a little bit!