Why Read Source Code? for New Devs

Ryan P Smith
Oct 28 · 9 min read
Image for post
Image for post

You’ve been coding for how long and you haven’t read any source code yet!? Just kidding, everything’s going to be ok. But seriously though… if you’re new to coding, you’re probably like me and are waiting too long to jump into a professional codebase to poke around. Today I want to walk you through some source code and see what lessons we can draw from this process.

The library that we are going to look at is Redux, “A Predictable State Container for JS Apps.” The lessons we take away today should translate regardless of the library that you choose to explore. But Redux has a small codebase, making it a great place for us to start on this journey. If you’re not familiar, Redux is an excellent tool for managing state, for the frontend of your applications. It plays beautifully with UI libraries and frameworks like React, Angular and many more.

Disclaimer — This article will not be how to, what is, or why Redux. Nor is it a deep dive into the Redux source code. We’re simply going to peek under the hood and see what we can learn from looking at professionally written code.

Wait… so why do we want to explore any codebase? Glad you asked! I think there is a lot to be gained from this process. As a new dev, you’ve likely started your coding journey with some tutorials, and then (hopefully) you’ve jumped into creating your own projects as quickly as you’re able. Rinse and repeat. But the pattern here is that you’re probably building these projects from a blank slate. This is great, and you feel empowered by what you’ve made from scratch, but this probably isn’t going to be your workflow in the real world. On the job, you’re going to be working in existing codebases, and you don’t want the first professional codebase you lay your eyes on to be the one of your new company. Reading and navigating through existing code is a distinct skill from writing it. You will want to spend time honing both of these skills. What’s great is that, by doing so, you will get more comfortable navigating code written by others, but you will also get exposure to new techniques and best practices for writing code like a pro! In this article, I will share a few of these lessons that I, myself, learned from this process.

Quick aside — I’d like to point out an additional benefit of what we’re doing here (though it’s not the focus of this article). By peeking under the hood of a tool that we use in practice, we will gain a better understanding of, and more confidence in that tool, when we put it to use. I don’t know about you, but I got into development for two reasons. I love to build, and I need to know how things work. The latter is the important one here. When you understand how something works, you can really own it. When that error is thrown, pointing you to your Redux store, you can sit back and say to yourself, I’ve seen the inner workings of this thing that I’m using. I know exactly what it wants, what it does, and what it’s giving back. With this knowledge, you can more easily see the issue you’ve created in your code… you gave it something it didn’t want! Bug: squashed; Dopamine: hit.

Alright that’s been enough, let’s take a look at some code. You can view the source code directly in GitHub or you may choose to clone down the code to your machine.

mkdir ReduxClonecd ReduxClonegit clone https://github.com/reduxjs/redux.git

Feel free to set a timer for 5 minutes and wonder aimlessly through the files. We don’t need to take away a deep understanding of everything going on here, but it will be helpful to just get familiar with the project structure.

Image for post
Image for post
Dev reading through code

Now that you’ve poked around a bit, and if you’re only familiar with JavaScript, you may see some unfamiliar code. Did you notice that most of the file extensions are ? Redux is written in TypeScript, not JavaScript. (I will refer to TypeScript and JavaScript as TS and JS, respectively, moving forward.) But don’t go running just yet, this is our first opportunity for growth. Let’s head straight to the TS docs and we’ll see that “All valid JavaScript code is also TypeScript code.” That sounds good. But if all valid JS is TS, we can infer that all valid TS is not necessarily JS. So let’s get a surface level understanding of what TS is and how we can expect it to look. We’re not learning TS here, we just want to know how to navigate it.

Let’s take a look at the handbook docs provided by TypeScript. We’ll jump right to the “TypeScript for JavaScript Programmers” section:

For example, to create an object with an inferred type which includes and , you can write:

const user = {
name: "Hayes",
id: 0,
};

You can explicitly describe this object’s shape using an declaration:

interface User {
name: string;
id: number;
}

You can then declare that a JavaScript object conforms to the shape of your new by using syntax like after a variable declaration:

const user: User = {
name: "Hayes",
id: 0,
};

Since JavaScript supports classes and object-oriented programming, so does TypeScript. You can use an interface declaration with classes:

interface User {
name: string;
id: number;
}
class UserAccount {
name: string;
id: number;
constructor(name: string, id: number) {
this.name = name;
this.id = id;
}
}
const user: User = new UserAccount("Murphy", 1);

Great. I think this knowledge will help us in our journey. All we need to takeaway here is that TS allows for type declaration. And now we have some surface level understanding of the syntax involved with doing so. The TS docs are always there, If you’d like to figure out exactly what some piece of code is doing. But for now, this should be enough information to help us parse out some of the syntax coming from the TS language, in the Redux code.

Let’s jump to line 244 of the Redux code (subject to change):

try { isDispatching = true currentState = currentReducer(currentState, action)} finally { isDispatching = false}

What do we have here? A try block, I know those, but what is this syntax and where is the catch!? I’ve been using try…catch statements for a little while, but I’ve never heard of the finally block myself. When learning a new concept, I like to head straight to documentation. In this case, we’ll go to MDN to read up on it… So it’s looking like a finally block will execute after your try and try…catch statements. And we already knew that we can use a try…catch without a finally. So, as stated by MDN:

This gives us three forms for the statement:

Now we know a bit about how this thing executes, but I’m still having a hard time thinking of a use case. So let’s continue our research on this one. Let’s look up, “when to use finally block?” I like this response from this Stack Overflow question:

By using a finally block, you can clean up any resources that are allocated in a try block, and you can run code even if an exception occurs in the try block. Typically, the statements of a finally block run when control leaves a try statement. The transfer of control can occur as a result of normal execution, of execution of a break, continue, goto, or return statement, or of propagation of an exception out of the try statement.

Ahh, now I see…

Image for post
Image for post
Gazing into a crystal ball

I think the key word here is “clean up” code. I’m thinking of a time when I was coding up a frontend message that needed to display before an image upload resolved. The loading message needed to be cleared in the local scope of my logic whether the upload failed or succeeded. A finally block would have been handy in that situation. For me, this is what it’s all about. Learning a new concept is always nice. But learning a new concept and connecting with it, in such a way that you can envision it making your life (and your code) better? Well that… that’s when I get excited.

I’ll also leave this short article here for some interesting facts about the finally statement.

Cool, so we’ve picked up a couple things to this point. Let’s dive back into the source code and see where it takes us next. If we head right back to where we left off, I’m noticing something that has been a theme throughout the entire codebase. Comments. And lots of them. Not only that, but did you see that there is an entire directory, , dedicated to just documentation? I think this is a big one in terms of what we can learn from pro code, as new devs. As stated earlier, when we are starting out in the world of development, it is so often the case that we work in isolation. You know how to add a comment in your language, but you’re probably using it most often as a tool to temporarily stop some piece of code from executing. Or maybe writing some small, not-so-well-thought-out ‘note to self’ (more on this in a bit). But well thought out comments and documentation are an integral part of the development process.

Of course, on the job, this is going to be a mandatory skill. You may know that, but you still think to yourself, “I don’t need a comment here, on my small learning project that no one else will ever read.” I’ve caught myself in this trap before. You write out a beautiful block of code, achieving exactly what you set out to do. It makes so much sense. It’s elegant even. But let me tell you, when you come back to this code, some 3 projects and 2 months later, it’s not going to be as clear as the day you wrote it (if it’s clear at all). This is just the nature of what we do. When you’re deep in a project, you have a picture in your mind of how all the different pieces of the puzzle fit together. But as soon as you disconnect from the code for some time, this can be lost. It can, of course, be regained, but that requires time. Time that you could have been more productive with. The point I’m getting at here is that comments are your friend. And more specifically, that you should be adding useful documentation to your code, at the time in which you currently need it the least (the trap that I mentioned before). By doing so, your future self (and other collaborators) will thank you when you head back into that project to look something up or to make some change.

A quick side tip — Of course, not all comments are polished ones for export. Sometimes you just want to make a ‘note to self’ for some code, in development, that you know will need to be refactored. When this is the case, I like to include some keyword as a flag. This way, when I’m doing some code housekeeping, I can easily search the project for those types of comments that should be removed when the time is right.

So let’s reflect here for a moment. We learned a tiny bit about TypeScript. Something that we may not have had much, if any, exposure to before. Maybe this piqued our interest, and we decide it will benefit us to learn it. We picked up a new piece of syntax, in our own language, that we can put to use immediately. And finally, we discovered, or at least we were reminded of, the importance of good documentation.

I hope that this exercise has exemplified how reading source code can make you better as a developer. I hope you can see, from these small examples, how far this process can take you. And finally, I hope that you continue on this wonderful journey exploring source code!

The Startup

Medium's largest active publication, followed by +734K people. Follow to join our community.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store