This week we are tasked to find a colleague among our classmates, exchange our repos and review each other's code. I reached out to this cool fella on Slack.

The instructions were pretty clear: I forked his repo and cloned it to my local machine. I set up the project very quickly thanks to his clearly-written README file (and npm of course!).

The project is a comment generator for code of various languages. You specify one or more input files, and the program gives you the same code back, with comments above each line.

I started by going through all the example commands given in the README file. Then, I checked the help message with -h and played around with different options and input files. Eventually, I was able to find some issues.

• [BUG] Default language model results in error if using a different API provider

This project was made using OpenRouter as the LLM provider. You can change it by setting an environment variable. However, with any other provider, the program simply wouldn't run unless the -m <model> option is used.

• [BUG] Output file is overwritten if provided multiple input sources

The program supports multiple input files. However, if the "output to file" -o option is used, the file is overwritten with each output.

• [BUG] Output contains Markdown notations

With certain language models, the output contains extra Markdown code block notations, which is a habit of most LLMs when outputting code.

I actually had a lot of fun testing. There's something satisfying about setting up a project and eventually make it work. Fortunately, I didn't run into technical issues, but it was quite a challenge to go through all the project files and understand them from the ground up.

Now onto (my repo)[https://github.com/theoforger/mastermind]. I also received some issues from my colleague:

• Improve Error Message for Missing or Invalid .env Configuration

Environmental variables were read without any validation. And errors from API calls weren't handled at all. I have introduced such error handling since them. The issue was fixed.

• -v flag does not display version

-V is used to display version instead of -v. This is an upstream decision from the crate clap. Although an override solution is provided in the discussion, I decided to stick with the convention and closed the issue.

• [Feature]: Add Validation for Empty Input Files

The content of input files weren't validated. The program would take any file even if it's empty. I later implemented the code to make sure the files are not empty.

It was interesting having someone else look at my code. I knew there would be bugs related to API calls due to the lack of error handling, but I wasn't thinking about the file validation aspect at all. Also, having an issue open on my repo surely motivated me to work on the fixes much sooner than I would otherwise!

During this collaboration, I mostly used GitHub to communicate with my colleague. I like the asynchronous aspect where I have all the time to gather the information I need before filing an issue. However, it does take forever to reach the other person, so I usually drop a message on Slack as well.

Here are some more things I learned:

• Issues, Tags.
• Branches, Pull requests.
• I don't need to understand the entire project to troubleshoot an issue.
• A well-structured project goes a long way, even if it's a small one.
• In most cases, .env files are read at runtime, not compile time.
• In Rust, I can set the return type to Result<..., Box<dyn std::error::Error>> to incorporate different types of errors.
• .map_err() is very useful to transform one type of error to another.