Moving into a Large Codebase

closed account (S6k9GNh0)
I don't understand how people suddenly jump into a codebase and are able to implement a certain feature, small or large, given there little knowledge of the entire codebase. I recently had an issue with GDK and wanted to try my hand at a new backend for it (a daunting but needed task). But there are so many unknowns with so little documentation for the implementer, I'm unsure of really where to begin. And while I am able to start reading code after code, I find myself spending more code trying to familiarize myself with the codebase than I am writing code and it's quite obvious it will take me weeks, if not months, at the pace I'm going.

Is this a normal feeling and/or reaction? I'm really not used to doing stuff like this but I've had more time on my hands recently, and I'd like to be able to eventually contribute (more than just a line or two) to any project I like, specifically towards things like an open-source game or significant library that I didn't create.

I've also been searching for tools that will analyze code to tell me the path a function takes or where a function is called from. I'm unsure of any as of yet so any advice here would be lovely as well.
Last edited on
It certainly seems like it would take a while to "get into" something. I mean when you first worked with the STL and stuff you didn't try to make a new allocator for memory management (did you? lol)

I think that it'd take some time to learn how it works and what is generally used for what.

I've also been searching for tools that will analyze code to tell me the path a function takes or where a function is called from. I'm unsure of any as of yet so any advice here would be lovely as well.


VC++ has a "Find All References" search option for finding references to functions or variables. Don't know of anything else that does that but I'm sure someone has done something.

Not really sure what you mean by "path a function takes" though.
closed account (S6k9GNh0)
I mean the opposite of "where a function is called from" as in "where/what a function calls". I was hoping for some semi-complex tool that would possibly draw me a tree-like structure. But this perhaps hasn't been made yet... worse case scenario, that ends up my project instead.
Last edited on
I had the same problem when I was getting into the Winsock API. I spent three weeks writing a whole bunch of bs code, and it wasn't until then that I finally got a grasp on all the structures and functions that MSDN provides so little documentation for. I think it's quite normal to take a while to familiarize yourself with a library or API that doesn't have too much documentation. Actually, I think you should be worried if it didn't take you much time to get the hang of.
Even things like Qt that have notoriously good documentation took me a while to get the hang of because there are sooo many things involved in it.

Don't worry, though. You're not alone in that.
As a beginner to third party libraries and APIs, I have never thought of actually spending any good amount of time just familiarizing myself with an API. Usually my strategy is get an idea, found a library that can accomplish it, then go into writing what I think will be final code. I always end up get frustrated and quitting. I think I'll try this new (obvious) plan of just writing bs code till I'm more familiar with an API
I think what computerquip was refering to was getting familiar with the code to be able to make contributions to the project and not just to use an API, but I could be wrong.
You shouldn't need to look at the code of am API to use it, unless said APIs documentation is shit.
Last edited on
Generally if the documentation is that bad then you shouldn't want to use the API any way.
I don't understand how people suddenly jump into a codebase and are able to implement a certain feature, small or large, given there little knowledge of the entire codebase.


It happens much too often and is one of the leading causes of open-source code-base butchery. Such people often make contributions to a project that go against the project's "intuitive normality" and are either not accepted, soon deprecated, soon refactored, or flat-out removed breaking backward compatibility.

If you're signing onto the project early enough (such that the original project leader(s) is / are still around), then there might be hope. Take as much time as you need to familiarize yourself with the various conventions, styles, and paradigms that the API uses and make efforts to speak with the project coordinators rather than randoms that paste a line or two of code here and there.
Topic archived. No new replies allowed.