Contributing to open-source doesn't stop at adding features and fixing bugs. Sometimes, you can do more than you might think just by performing code reviews. In this week of my open-source journey, I'll share some of my experiences when performing code reviews.
The project where I'll be doing this was my school IPC144 curriculum renewal. With many students working on the repository, it is essential to review and test incoming PRs regularly. Surprisingly, I didn't have any trouble looking for issues this time.
Here are the issues that I decided to perform the code reviewing on:
In the first issue, I wanted to check if the person escaped the special characters with "\," as some of them didn't get converted properly when formatting with Prettier. An example of this was on line 115-128, when the asterisks were replaced with underscores:
// Original
* Giga or G (=1024M): 1 Gigabyte = 1024 * 1024 * 1024 bytes ~ 10<sup>9</sup> bytes
// Expected
* Giga or G (=1024M): 1 Gigabyte = 1024 \* 1024 \* 1024 bytes ~ 10<sup>9</sup> bytes
// Actual
* Giga or G (=1024M): 1 Gigabyte = 1024 _ 1024 _ 1024 bytes ~ 10<sup>9</sup> bytes
For the second issue, I mainly focused on addressing what the contributor was missing in the list of requirements, specifically:
- Using backticks and all code for memory addresses and such in tables that use things like void, int, function names, memory addresses.
- Removing unnecessary changes
Code review is an excellent thing to do. By assisting others by leaving reviews and comments on the PR, not only will you improve the code quality of the PR, but you will also be able to learn some new stuff too.
To find out more about the problem in the first issue, you can check here.
Happy coding! 💻
Top comments (0)