Recently, I had the opportunity to submit my first open-source pull request to a project of similar scope to the CLI text->HTML translator I had developed. However this time, I was developing in C#, another language I enjoy programming in.
The repo can be found here
The process wasn't too difficult; add ONE markdown feature for translation to the other student's solution. This meant any of the following could be added: h1, h2, links, bold or italics and must be added through simple file reading, meaning no libraries were allowed to be used.
Naturally, h1 and h2 seemed to be the easiest to add, so I got to work. The codebase was well-written and made it easy for me to add such features to the solution. The contents of files were already trimmed and placed into an array, this meant every new line was a separate index in the array. Simply going through each index and checking the start of the line using the
.StartsWith() built-in function was enough to add h1 and h2 support.
Although the job was done, I wanted to try something new so I decided to add markdown link support as well. This was far more challenging than the previous 2 additions considering how different HTML and markdown link tags are. As soon as the consideration for adding link support filled my mind, I knew right from the get-go that regex was to be involved. I tried my hand at this complex regex problem through Regex101 and remembered how not-so-great I am at solving regex problems. After much trial and error and cross-referencing with other complex regex solutions, I was able to finally crack the code and after checking the different regex groups, boom, the problem had been solved and markdown link support was added.
Finally, it came time to file my pull request with the user. Similarly to my Code Review blog, PRs are a great way of making sure changes make sense. I made a few mistakes when creating the changes which added unnecessary redundancy to the code as well as some formatting issues with the generated HTML files. Thankfully, the owner of the repo found it and asked me to change the problems. The issue I filed to add MD support can be found here.
The only problems I really faced when developing the new feature were more so with the IDE I was using. I haven't coded in C# (or C/++ for that matter) in a long while - mainly for smaller projects which could be done in vscode. With such a large project, especially one made specifically in Visual Studio, I decided to use Visual Studio 2019 to fix up the project which ended up causing me some problems with compiling and IntelliSense. To make this short, I installed a newer version, Visual Studio 2022, and everything worked perfectly fine.
Well, first and foremost I learned the importance of communication with project owners. A lot of the issues I had to fix in an update to my PR were mainly formatting discrepancies between what the owner of the repo wanted vs. what I didn't think would be too important. Had I consulted them, an update to the PR would not have been necessary.
With the lab complete and everything all fixed - what would I have done differently in hindsight? Well, I think putting more importance on communication would've been #1 even though we did go over certain aspects of the codebase through a call, I should've been more adamant about asking if what I implemented was put to spec. Secondly, I definitely should have looked into the changes I was making and how they could've affected other aspects of the output. Lastly, Having a comprehensive list of all the changes made would have made review a lot easier for both parties.
The issue filed on my repo can be found here
The PR & issue provided on my repo was very thorough in its implementation and little to no issues were found. I mistakenly overlooked a single error in the README and ended up reopening the issue so they could file another PR with the single change.
Thanks for reading this post, even if it ended up being a lot longer than I had hoped for, I enjoyed recollecting all my thoughts when developing everything.