Many programmers will tell you they enjoy the freedom they have in creating solutions for various problems using programming. For me this was a bit of a shock in second semester, because I really enjoyed programming with rules and guidelines. Don't get me wrong, I can be creative - I just prefer to have consistency.
Consistency is something that is completely difficult to achieve when having various contributors in a repository. Many programmers have different coding styles, it's like our signatures. However, we often don't see many open source codebases with different tab spaces, semicolon use, new lines etc. This is because most of them use Static Tool Analysis.
Static Tool Analysis
This week we learned what static tool analysis was. Essentially they are tools which help avoid "nits" or otherwise known style differences in the code base.
This week I added four tools to my static-site-generator application to help other contributors have an easier time reading and writing code.
contributing.md
I created a contributing.md file. Here I wrote out a thank you to any future contributors, and listed all the requirements to help you get started to contribute to my repository. Additionally, I made sure to provide links to any external applications they might require (i.e Visual Studio code and NodeJs).
Source Code Formatter
I remember first installing Prettier in Web222 and thinking what a burden it was. Currently, I have the extension in my IDE and always runs when I save a file. I actually can't live without it! I knew I was going to use Prettier for the formatter.
The installation for Prettier was actually very easy.
I went to their website and clicked on the 
Next I got a guide to install every other static analysis tool I would be needing. This guide was extremely helpful and I recommend it to anyone who wants to create guidelines in their code base.
Result: After running the source code formatter I did not have much differences in my files (I already run prettier when I save any file). What did happen that I thought was funny was I had forgotten to add the dist folder in the prettier ignore file - and it produced and error in the terminal.
Linter
Once I had done this, I read ahead and installed the eslint-config-prettier. This is where I hit a bit of a roadblock because the instructions were different than the files I was working with. I then realized that eslint-config-prettier requires the actual package for eslint. I used this blog to install ES lint and followed the steps. I liked that they provided with an explanation of the types of style guides - something I didn't really understand. They provided a nice table so that you can see the differences between the tree.
Result: I was a bit shocked to see at all the changes here. I am still trying to understand why there was so many, so that I can better understand what the linter is responsible for.
IDE Integration
IDE's can have integration by using a .vscode folder with the extensions.json and settings.json This will allow for all contributors to have access to the same settings and extensions - another way to stay consistent.
Git Pre-Commit Hook
Again, the guide I posted above provided the steps for installing Husky which is able to run a Pre-Commit Hook. I did run into some problems when I went to execute the npm set-script prepare "husky install". Luckily the guide had explained that the set-script command will not work if your node package module version is less than 7.X. I was able to quickly install the latest npm by using npm install -g npm@latest.
Conclusion
Although I was completely tired today, and ready to just sleep - setting up everything took only 30 minutes. If it wasn't for the guide I have vouched for over 100 times in this blog, it might have taken more time. I am really pleased with the ease of setting up all of this - something that every project should do. It was really funny to think about how developers actually sat down and nit-picked each guideline violations in every PR. I honestly am not even sure I know most of the guidelines - I've had the privilege of learning to code in a time that has established static analysis tools. In conclusion, this really makes you appreciate the open source community(ES-lint, prettier, Husky - all open source!) and their general ability to solve problems - even in programming development.
Top comments (0)