Coding style and linting

Coding style

Since we are all new to writing TypeScript code, we will end up writing it in different styles. That is fine... for your personal projects. When collaborating with other people on the same project, it becomes important to ensure a consistent coding style. A consistent style slowly removes the mental overhead of trying to understand the text and its layout before you can understand the meaning of the code itself. As you read different pieces of code in the same style over and over, you become used to the style and you start understanding the meaning of the code faster.

Code style is not only the visual appearance of the code you write. It is also the idioms you use while writing your code. Idioms are the conventional way of expressing the same meaning in a specific programming language. For example, writing a loop to go over a list/array of things in a language like C/C++ can be done in two ways:

• Pattern A:

      for (int i = 0; i < length; i++) { ... }
  

• Pattern B:

      int i = 0;
      while (i < length) { ...; i++; }
  

The idiomatic pattern in a language like C/C++ is Pattern A. That's all you need to know about idioms for now. They are not something you can memorize, but they are patterns you can notice in code that more experienced people have written. For more discussion on idioms, read this StackOverflow thread.

Linting

It is hard to know what the idioms and conventional styles are in a language you don't know yet! Even for experienced programmers, they are only human (I hope) and could make stylistic and idiomatic errors. Fortunately, we have tools to check our code for many common style issues and fix them for us. We are going to use three such tools in our project.

• ESLint for catching TypeScript/React syntax errors
• Prettier for formatting TypeScript/React code
• stylelint for CSS code

You do not need to worry about how they work and what rules they enforce about our code... yet. As you work on this project, you will make styling errors. These tools will either catch these errors for you and tell you, or fix them automatically.

VSCode has much better support for these plugins and tools than Sublime Text does. It is recommended that you use VSCode for this project, but you are welcome to figure out the kinks on your own using Sublime Text, if you choose that instead.

We do need to set these tools up in our editors:

1. Install the Prettier plugin. It is called "Prettier" under Extensions for VS Code, and "JsPrettier" on Sublime Text. You will need to figure out on your own how to install these.

2. Install the ESLint plugin. It is called "ESLint" on both Sublime Text and VS Code.

3. Install the stylelint plugin. It is called "stylelint" on VS Code and "SublimeLinter-stylelint" on Sublime Text.

4. If you are on Windows, there might be additional setup steps required. You can either meet up with other Windows users and me, or figure out on your own how to do these steps.

5. If you are on VSCode, go to settings. You can open the VSCode command palette (an easy way to access functionality) using cmd/ctrl + shift + p, and then type "settings", and press enter. Search for the setting "Format on Save" and turn it on. This will run the linters every time you save a file.

6. Just to double-check your changes for styling errors, before committing your code, make sure you run yarn eslint, yarn stylelint and yarn prettier-write from within the client directory. To see what these commands do, you can look under the scripts key in the package.json file.

Travis CI

I have set the repository up to run the linters before any code can be merged into master. These linters are run using a service called Travis CI, if you are curious. You will see this appearing as a "check" when you start creating pull requests. For now, just know that you will need to format your code correctly if the checks fail. 😺