Code validation, conventions, linting

Date 16/09/2014

First assignment is given.

Why code style, validation and linting matters?

Whether there is just one or more developers working on a given code base, over time it comes difficult to read one's own code if the code style differs. Any shared code should follow certain style guides for making it consistent.

Code validation checks against syntax failures, possible naming collitions and other relevant things that might be needed in order for the code to work in a given set of environments. What works in one browser, might not work in another.

For Node.js, the environment is somewhat stable and while updating patch level (0.0.x) versions, should not break existing code. Also since is is always made from the same basic components, namely V8, it has somewhat similar runtime expectations between minor (0.x.0) versions.

Code linting validates and evaluates code against a set of given rules, usually based on code style and validation best practises, as well as personal taste.

Tasks for the day

Use the repository hello-node-js that was created during the previous lecture.

  1. Automatic Semicolon Insertion (ASI) is a handy helper found in many browsers, but it is usually best to be avoided

    • Found out about ASI and write about it few lines in your README.md

    • Validate your code, task-*.js files against ASI and add a validation configuration file in your repository

  2. Choose an existing Node.js module from npm which does not have code validation included

    • Create a fork from its source

    • Add code validation configuration, which would approximately match the existing code style used in that module

    • Optional: Create pull request to the module

    • Link your pull request or fork to the list below

  3. Take a look at the source codes of the following linters and observe how they are achieving similar

    things differently. Then write down in your hello-node-js repository linters-study.md file

    about the similarities and differences, as well as external module usage.

    Write a short configuration example how to prevent ASI failures, for each three linters

  4. Optional: Write a rule for one of the three linters

    • Create a new repository or clone the original linter project

    • Instead of using the master branch, create a new branch with name of your new rule, prepended by rule-

    • Feeling adventurous: create a pull request to the linter project for adding your rule in it.

Links to the pull requests and forks made for task 2

Links related to the lecture subject

Examples for the tasks

PreviousModules and npmNextHTTP, Connect, Express

Last updated