The Teacher and Enforcer in Style Linters and HTML Validators

I have been a software developer for one month and slightly over three weeks now and there are a couple of tools, tricks and techniques which I did not know of before but have appreciated so far. Some of those that stand out for me are the style linters and the HTML validators. To start with, my conscience is bemused at the imagination of how someone could even conceptualize such ideas. Well, I guess I will be conceptualizing similar ideas a while later.

With a bemused conscience, I have decided to write about what I learned by using the style linters and HTML validators. These tools will teach one (especially a newbie to coding) best coding practices while they catch and sometimes resolve code bugs. Pretty interesting right! It gets better because worrying about code indentation, missing semicolons, and the like is something of the past since style linters will catch them and sometimes correct them.

By now, some of you are asking what in coding are style linters and HTML validators, so I will import some definitions for you here.

Well, I will define the HTML validator based on my experience using it.
It is a web application that will run through every line of your HTML code and provide you a detailed report of the warnings and errors where your code does not follow the standard HTML page layout.

It is interesting how the validator will quote for you the line and the specific column in that line of where the error/warning has been found. Huh, wise right! Some of the common errors/warnings reported by the HTML validator relate to the semantic HTML layout. Now semantic HTML layout is emphasized in HTML 5 and it is intended to make interpretation of the HTML structure easy to understand for both the browser and any other person reading the code.

The HTML validator I have used so far is found at https://validator.w3.org/. It is very user friendly and free to use. You just need to know the URL (Luckily I have provided it). Then you can copy and paste your HTML code in the HTML validator or you can upload your HTML file to the HTML validator. Either way, it will catch the errors and warn you on what in your code does not abide by the standard. Once you have the report of errors and warnings caught by the validator, you need to go to your HTML
file and correct these errors. If you feel satisfied with your corrections, you
should re-validate the HTML code by either copying your updated HTML code and pasting it in the HTML validator or uploading the updated HTML file.

So by going through this process, one is able to learn new things about HTML elements and their markup usage. Right now, I am hoping you are in consensus with me that this is an excellent way to enforce and teach the appropriate usage of the HTML elements in creating markup.

Well, I was able to take a screenshot of some of the errors/warnings that I have had to correct in my markup and I will share it here to illustrate my sentiments expressed above.

So for example if I referred to error number 3 in the screenshot above that says “Start tag seen without seeing a doctype first”, resolving this error can only mean that I should have a doctype first for every markup I write and thus I will have learned the importance and use of the doctype keyword. As such, I see the teacher and the enforcer in the HTML validator at W3.

A linter is a tool that analyses your source code to flag programming errors, bugs, stylistic errors, and suspicious constructs (source: Wikipedia). Style linters are specific to CSS style rules and are used to keep CSS code in check.

From the brief experience I have had with style linters, there are many extensions that plugin to most code editors and can perform stylelinting, although the best way with which I have been able to learn from style linters is by configuring them to catch and flag the errors so that I can fix the errors/warnings manually.  As of now, I have been exposed to using the Stickler Stylelint configuration. Here, Stickler is an application that is used to enable the linter and Stylelint is the linter tool that is used to keep the code in check.

By using the Stickler Stylelint configuration, it is possible to catch Stylelint errors both in the local development environment (probably your editor) and in the remote repository. Wonder not about how the dual stylelinting is achieved, it is very simple and I will show how in the next paragraphs if you will stick on.

First of all, if you would like to read more on Stickler, you can check out this link https://stickler-ci.com/. Now, Stickler is very user friendly and free to use. I will start with what I found easiest to set up Stickler configuration in your remote repository.

Stickler is a third party application that is integrated into GitHub. So you have to install it in your GitHub account by opening the Stickler official website on https://stickler-ci.com/. Then choose the install our GitHub application option and you will be redirected to your GitHub account
at https://github.com/apps/stickler-ci. Here you will make your Stickler configurations based on your preferences.

Back to the official Stickler website, you will be provided a toggle switch
(illustrated below) to activate and deactivate stickler on and off any of your
repositories. If you activate Stickler on your repository, it will then go
ahead and create a pull request in your repository seeking to merge the
stickler configuration files into your branch.

Once you merge the pull request to your branch, the configuration files will be added to your repository branch and the magic will ensue. Henceforth, everything that is committed to your repository will be subjected to Stylelint checks and you will be presented with findings of the checks. The findings will ask you to make changes in your code so that it meets the set standards. By this, when code is written by collaboration of various awesome developers or in a team, it will appear as though it was written by one developer. Simply put, it ensures uniformity of code written across a team or teams which has enormous benefits in the world of coding. One of the benefits is that it is easy for everyone on the team to read the code. So I guess, it is a worthy tool to have in the toolbox in your company or on your project.

To illustrate my sentiments above, I will share some screenshots of the toggle button to activate stickler on the remote repository and how the checks appear in the remote repository.

Please note that in order for stickler stylelint checks to show in your repository, you need to open a pull request after activating Stickler on your repository. The style lint checks will display where the commit history ends in the pull request or you can access them by clicking the Checks tab found in the top navigation bar of the pull request. Below is a screenshot of how the checks will display in the pull request.

Passed stickler checks in the remote repository

Failed stickler checks in the remote repository.

With stickler properly activated on the remote repository, next would be to configure Stickler and Stylelint in the local environment. Thanks to the creator(s), all you need is to define your style rule standards and save them in a file that you HAVE to name “stylelint.config.js” and add this file to your local project folder. You also HAVE to add another file to your local folder that you SHOULD name “.stickler.yml” (Key to note that this name starts with a “.”). In this file, is where you will specify the linters that are enabled and the path to the standard style rules that you saved in the “stylelint.config.js”.  

I will provide examples of these files in the screenshots below. In these screenshots below, we have stylelint as the enabled linter.

Descriptive example of .stickler.yml file structure

Example of a stylelint.config.js file

If you have the .stickler.yml and stylelint.config.js files added to your local project folder, then you are good to be notified of any CSS code you write that does not abide by the style rule standards defined in the config.stylelint.js.

Your local folder should look like this when the files have been added.

When Stickler is configured properly, Stylelint will catch the error/warnings in the style rules and highlight the line where the errors/warnings are with a red sinusoidal underline (Danger!).

Additionally, the report of errors/warnings can be found under the PROBLEMS tab in the terminal of your editor.

Like before, I took some screenshots to illustrate the errors as reported by Stylelint.

How Stylelint errors/warnings are highlighted.

Some of the error examples can be seen in the following screenshot.

As seen in the screenshot above, even missing a semicolon where the rules defined in your stylelint.config.js file require a semicolon will be regarded as “SIN” by Stylelint.

When you have manually resolved stylelint errors a couple of times, you become accustomed to the expected style rule standards and in turn you develop excellent coding practices. This is where the component of teacher and enforcer is embedded in the use of stylelinters.

If you reading this line, then congratulations upon having read all I had to write about the lessons that one (especially a newbie to coding) will learn if they use the stylelinters and the HTML validator. The lessons are actually implied because the primary purpose of the stylelinters and the HTML validators is to flag programming errors. I will end this piece with a note that there are linters for other languages like Ruby, and JavaScript
although this post focused on stylelinters. However, I believe the implied
lessons that are embedded within their usage are universal across all.