How does one read codebases?

[alayek]

I think this is the hallmark of an engineer. To be able to know the relevant codebases inside out. Be it codebases at work, or open source example apps' repos.

I like to read codebases. I have learned a lot from reading code on GitHub. I like the Octotree extension that allows me to navigate easily, without having to clone it locally.

I have formed a mental map of sort - where to start, what to look for in each file, what order to follow etc. For instance, I start with package.json, to check the deps and scripts. Then I check the eslint setup, then the tests. After I have an idea of what to expect from the project, I start reading the source code.

But this is where I usually lose attention, or just lose interest in general.

What should I do after this? How much of the codebase I should know in detail, how much of it I should keep in my head at a higher level? What strategy do you follow?

---

I have noticed that it's easier to read parts of codebases, if you are trying to understand something specific from it, or modifying a small part of it.

[kentcdodds]

Here's your answer in 3 minute audio form!

[alayek]

Thanks a bunch for the detailed reply!

I asked a similar question to Jan Orvadko, lead maintainer of Firebug, about 3 years ago. Back then, I was just trying to understand the Firebug net panel (I didn't even know call(), bind(), apply() etc.).

He also provided a similar reply - because the code is version controlled, checkout a new branch and test your hypothesis. If you think a part of the code does something, put that to test by altering that part of the code. Basically his suggestion was to instead of passively reading the code, experiment with it.

One other technique I followed was to go through commit history. I took the 2048 codebase, and checked out each commit in reverse chronological order. This was not only showing me the code, but also the author's mind at work.

For instance, in case of 2048, the author first added the SCSS styles, then the HTML markup, and about 20 commits after that - the actual JS logic started to take shape. This gives me confidence when I am trying to build any app - because I know this approach worked for someone else.

But again, for codebases with more than 200 commits, it won't be manageable.

Recently, I am learning React Native with Redux using the GitHub compare feature, like this.

---

I liked the part about your reply that you don't read the code always - at least if you can help it. I think that's also what I have realized so far; that there has to be an end goal to read the codebase. Don't read code just for the sake of reading!

P.S.: My name is pronounced as Or-i-jit (Or as in Oregon, i as in Chilli's, jit as in Ve-get-a)

[kentcdodds]

Thanks for sharing!

P.S.: My name is pronounced as Or-i-jit (Or as in Oregon, i as in Chilli's, jit as in Ve-get-a)

I'm still unsure of how to pronounce your name! Chilli's has two is in it, and I'm not sure I've heard the word "Vegeta" before! Haha