In my Open-Source course this week we worked on completing a small project to convert text files to HTML files. While it wasn't due for a couple of days after this task; before then we needed to review another student's release and get ours reviewed.
To get someone to review my project I made use of Slack where I listed my GitHub repo asking for someone to provide feedback for it by creating issues in GitHub. I responded to another request of someone to have their project reviewed which allowed me to find someone who did not have any feedback already and was willing to examine my project.
When testing and reviewing my partner's code I found we both used the same programming language, Python which I am very unfamiliar with. Initially, when looking at the code I saw that they were more proficient and used a lot of different methods that I was unaware of. Through testing, I found that their code was solid and worked fine under a lot of different circumstances, and was learning from just looking at their code. For example, I was unaware you could run a Python script using the ./{python program} method if you gave the file execute privileges as I kept using the python <program name> method.
Getting my project reviewed I thought my partner who looked more proficient in Python would be more critical of my implementation. However, they focused more on the project details and future flexibility of the code which I would find helpful. Instead of going into detail on things that I might have overlooked when it came to efficiency.
The main issue that I found in my partner's project was that they were missing many README details including installation instructions making it slightly unclear to someone trying to install it. The other issue/improvement I found was when a text file was converted to HTML it didn't add any `
tags for when there was a double newline. This meant that if there were any extra spacings between paragraphs they wouldn't be in the HTML document. This however was something that was optional and something that each project creator could choose to include or not but mentioned as an improvement.
Issues with my partner's project:
Issue 1 | In this issue I discussed how my partner's README could be improved as theirs was lacking some of the required details and details that could help one understand how to use the program.
Issue 2 | In this issue I discussed how their version and help flags could use some improvements including more details on how to run the program in the --help tag.
Issue 3 | This issue dealt with the fact that any optional features that are present in the project are not documented or explained and suggested a feature that could be added for future optional requirements.
Issue 4 | This issue dealt with how their program dealt with spaces in HTML and how they could have included some <br /> tags to more accurately reflect the text document they were processing.
Issue 5 | This issue dealt with code formatting issues and for them to add a couple more comments in the program.
Issues for my project:
Issue 1 & Issue 4 | These issues dealt with reformatting of the README document to make it more user friendly and optimized. This involved moving some sections closer to the top and making sure to use constant styling.
Issue 2 | This issue dealt with displaying the differences between different versions and creating a changelog to document them in the readme.
Issue 3 | This issue was about an error in my help message that showed an incorrect use of the program when used.
Issue 5 | This was an issue that one of my initial functions was not dynamic enough that it could be expanded upon in the future so they suggested I make it able to fulfill future users requirements.
These issues made by my partner helped me document my project more efficiently and helped with making sure my program passed all the specifications required for submission while also providing improvements to the code for flexibility in the future.
To sum it up, I gained a lot of experience opening and closing issues in GitHub and testing another person's program, and found that you can learn a lot from reviewing other people's code. I feel like it is good to have someone with a fresh perspective view code that is not theirs as they can catch things that others can't.
Top comments (0)