This content originally appeared on DEV Community and was authored by Hitesh Sachdeva
How did you go about doing your code reviews? Do you prefer an async or sync approach? Why?
I approached code reviews by first reading through the repository’s README to understand how the tool is supposed to work. Then I tested the tool locally with different inputs (files, directories, non-existent paths, large files, etc.) to see where it failed. After that, I read the source code (utils.js and index.js) to identify possible technical issues, like path handling, error handling, and file reading logic.
I prefer an async approach because it gives me more flexibility. I could test and review the code in my own time, document the issues, and then share them with the repo owner. Sync reviews are useful for quick feedback, but async gave me more time to dig deep into the project.
What was it like testing and reviewing someone else’s code? Did you run into any problems? Did anything surprise you?
Testing and reviewing someone else’s code was both interesting and challenging. I had to spend time understanding how the code worked before I could test it properly. The biggest challenge was identifying the difference between intended behavior vs. actual bugs.
One surprise was that the tool silently skipped files larger than 16KB without any warning. I expected it to at least log a message, so this was something that could confuse end-users.
What was it like having someone test and review your code? Were you surprised by anything?
When others started reviewing my code, I was a little nervous because I knew there were still rough edges and unfinished parts. At first, it felt uncomfortable having someone else point out gaps that I had missed. But as I went through the process, I realized that reviews aren’t about criticizing, they’re about making the project better. It actually felt encouraging once I saw how much valuable feedback came out of it. The surprising part was how even small issues, like unclear setup instructions, can make a big difference for someone else trying to use the tool.
What kind of issues came up in your testing and review? Discuss a few of them in detail.
During testing and review, I found a mix of functionality and usability issues. For example, passing a non-existent file caused unhandled exceptions because fs.statSync wasn’t properly checked. I also noticed cross-platform problems, like path concatenation using /, which may fail on Windows. On the usability side, the README lacked key details and had unclear instructions, making setup confusing. Finally, the tool silently skipped files larger than 16KB without notifying the user, which could lead to incomplete results. These issues showed me the importance of error handling, cross-platform compatibility, and clear documentation.
Provide links to issues you filed, and summarize what you found
I filed several issues during my review of the project:
Tool crashes when given non-existent files Missing error handling for invalid paths caused the tool to throw exceptions instead of showing a clear error message.
Path concatenation in buildTree may break on Windows The function used / directly instead of path.join(), which can create invalid paths on Windows systems.
readFileContents silently skips files larger than 16KBFiles exceeding the size limit were ignored without any warning, leading to incomplete outputs and confusion.
README has missing info and unclear instructions Documentation lacked project requirements and had unclear usage notes (e.g., npm link), making it harder for new users to set up the tool.
Were you able to fix all your issues? What was that like?
I haven’t fixed all the issues yet, I’m still working on them. Some are easier, like updating the README, while others take more time. Overall, it’s a work in progress.
What did you learn through the process of doing the testing and reviewing?
I learned that code review is not just about finding bugs, it’s also about improving usability, documentation, and maintainability. Testing another person’s project gave me insights into how users might interact with my own projects. I also realized that clear error messages and documentation are just as important as working code.
This content originally appeared on DEV Community and was authored by Hitesh Sachdeva