"Once you learn these tools, you'll never go back" I can say that this quote from David is 100% correct.
For this week's lab, we were required to setup a Contributing.md file to let other developers know how to setup our project in order to test out changes that are supposed to be made. We were also supposed to setup a linter and code formatter for our project. I decided to use black and pylint since my release 0.1 project was written in Python. Setting these tools up were simple enough. What I was more amazed with, were the amount of linter errors that came up based on the settings you pass into the .pylintrc file.
After setting up the linter and code formatter, we were also asked to setup default settings on our editor of choice with regards to having the linter and code formatter work by default. For me, this meant I had to make a .vscode folder that contained a settings.json file. This file would be loaded for the workspace every time a user cloned the repo. This file while not useful for me, is very much useful for every user that downloads/clones the repo. These settings allow them to run the linter and code formatter by default as soon as they save their files in the workspace. For those that don't use vscode, I also made a shell script that will execute black and pylint. The default action is to check the two python modules I created, but you can also pass in additional files as parameters in order to have black and pylint check them as well. When this was all done, I rebased, squashed, committed, and pushed my code to my repo on github.
This lab has shown me just how important a linter and code formatter are for open source projects, but also for projects in general. I don't think it's something I can work without now. Once you go linter/code formatter, you never go back.
Thanks for reading!
Top comments (0)