A Thing or Two About Code Reviews and Community

It’s interesting to see others do the same thing as you — but differently. Everyone in my class was assigned the same task, to make a command-line tool to search through an HTML file and find broken links, but after talking to different people about how they approached this task I realized that everyone has their own way of doing things. You could say that Haystack has some competition!

To find a partner to review my code, I let others know that I made my project in Python and was willing to review their code in return. Andre Bhaseen was the first to privately message me asking if I’d like to work with him and do a code review. We were both working with Python, and right off the bat you could tell that we had two different programs that both did similar things. To begin, I forked and cloned his Verify-URL repository and followed his README.md instructions. Immediately I noticed something must be wrong with my computer as setting up the virtual environment was a challenge. With a supplementary Google search, I managed to get the virtual Python environment working and his program to display the help section. Before reading the source code I wanted to test his program to see if I can use it only having read his README.md file. Aside from the virtual environment it was well documented and pretty straight forward, and I was using the tool as intended. Next I started to try and test special cases, inputting too many arguments, URLs that didn’t exist, invalid arguments. All were accounted for except when I inputted a valid HTML file name that didn’t exist. It gave me an exception telling me that FileNotFoundError. I noticed he checked the argument to see if it was in a valid format (.html) but didn’t check to see if that HTML file existed, nor did he handle the FileNotFoundError exception. I let him know the problem and filed an Issue on his GitHub repo. Looking at his source code I was surprised that he found a different method for extracting command line arguments; what I did was sys.argv to get the arguments along with a rudimentary if statement to handle the flow whereas he used a separate library called argparse. I think his solution handles the special cases better than mine, giving specific instruction as to where and what the user did wrong for each invalid argument. Furthermore, Andre used a different library to colour his text and also a different library to find the links within the file. I used regex to extract my links whereas he used BeautifulSoup4. I like my solutions better as it is easier for me to read, but I think in future releases I will use the argparse library for my Haystack.

Speaking of Haystack, Nesa Bertanico and Andre Bhaseen reviewed my code. Three issues were reported: there was no way to escape the script, inputting two arguments only executed one, and the grey colour was too dark. For the first issue, I honestly do not know where to start with this one, I would think that pressing Ctrl-C on any terminal program cancelled the process. I think for this solution I will appeal to the Open Source community for help. As for the second issue, this was done on purpose as I only want the first valid argument to be executed. Lastly, I tried replicating the text being too dark but I could not reach the same results as Andre. I think to fix this issue I will simply change the text to a warning colour like orange instead of grey. Colouring it orange instead of grey will look better on the pure black background of Window’s command prompt.

All in all I loved this first assignment, not just because I was given the freedom to choose what language and what libraries I wanted to use but also because I got to meet and collaborate with other creative Open Source developers. I feel that seeing other’s unique solutions to your challenges is eye opening in a way. Unlike other programming assignments, we were all encouraged to read other’s code and learn from it and after working with the Open Source community you can bet that your program will be better off. Having others read your code and review it allows you to realize your programs weaknesses. See, I read a saying somewhere that said “If you’re not open to constructive criticism then you're not open to truly growing as a person” which I think is especially relevant to new software developers who are growing their skills.

Student at Seneca for Software Development. Stay awhile, and lets learn something new together!