Posts Tagged

coding standards

What is Version Control in simple terms

In the past few months, I have spent my free time trying to support new developers to find their first commercial experience.

Usually I find that most of these candidates are not far off from being technically ready, but what they really lack is knowledge of the “ecosystem” that experienced developers passively use without even considering it important.

Today I am going to focus on Version Control. This post is not going to explain you how to use the tool ( there are lots of fantastic videos and courses our there than can do that for you), but is going to focus in explaining individual technical terms that are sometimes hard to understand without the proper explanation or example.

What is Version Control

Formally started in the 70s under the name of Source Code Control System, is one of the most used tool across team of developers. The actual definition of Version Control is:

Version control systems are a category of software tools that help a software team manage changes to source code over time.*

The main task achieved by version control is to orchestrate changes of files within the project. In simple words Version control software allow multiple developers to work on the same project at the same time, all without problem or possibility of overriding everyone else work.

The main reason why this tool is not very common in new developers is probably because it does not seem useful for a single developer, and people underestimate its hidden powers.

Master, Origin and the simple commands

To explain it further we are going to use some real life example to explain some of the technical terms used by developer. The example we are going to use is the one of a cloud storage like Dropbox or Google drive. Many of us use them on  day to day bases, and comparing Version Control to it should help in understanding some of the technical aspects and words used.


When working on a Project, all developers will have a copy of the project locally on their drive, but ORIGIN is a shared copy that holds all the information and is the true copy of the project. If you take the example of google drive, this will be the folder stored in the cloud, that all users of that google drive account can access from their browsers.


This is one of the most simple command in Version Control. This will allow a developer to update all the History of the files. This command does not actually changes any file locally, it is just used to show a developer is something is changed in Origin and inform the developer if the version of the files he is working on are up to date or need to be updated.

Using again the example of Google Drive, this happen every time a computer is switched on when the computed Synchronise with the Cloud folder, to see if anyone has changed any file.


The fetch command is sometimes omitted by developer, that tent to Update the file locally directly using the “pull” command. Issuing a “pull” command will behind the scene “fetch” all the information from “origin” and then it will download all the required changes on the developer machine to make sure that the project files are up to date. A succesful “pull” will mean that your local project files are the same of ORIGIN

Bringing back our simple example above, the Synchronisation of file is usually followed by this file behind downloaded and updated locally and this is what a “pull” does.


This is the last of the simple and most used command. All the above commands are used to grab information from origin, but “push” is used to update ORIGIN with local changes that we have done to files within the project.

A successful push will mean that your copy of the project and Origin are the same. It is important to note, that after someone “push” the code to origin, all other developer need to “pull” to have an up to date version of the code.

Master, Branches, Merges and Merge Conflict

Now that we have covered the simple commands, it is time to start and move to something a bit more complicated. In this art of the article, we are going to build a car to support our thinking and hopefully help explain this hard commands.


In small small projects all developers will work on the default Branch called Master. This will be the “only” representation of the project. But it is very common for developers to use Multiple branches within the project. Branches are usually used to develop feature, updates that a developer does not want to be part of master.


Depending form the outcome of our Branch work, we may need to combine the new feature with the main work “master” or in another “branch”. To do so, we need to use a command called “merge”. We usually merge a branch “into” another. More details will be given below with our example.

Merge Conflict

Unfortunately, not always everything ends well. Sometimes when Merging branches we may end up in conflict. This conflict occur when more than one developer have worked on the same file ( more precisely the same line) and the Version Control Software does not know how to deal with the changes. This situation is quite tricky and we will try to cover it in more details with the example below.

The production Line example

We are the proud owners of a single car production line. This establishment is called “master” in which we build our first version of the car.

We are now going to Experiment on the car to create an update on our current model. We take the finished car (pull from master) and we create a specific “branch” in the factory to add a feature to the car, a dashcam. After this feature has been added in my branch, and the engineer are happy with the change we “merge” our work back in the main production line (master). After doing so, every car will now come with a dashcam.

We are now going to carry two experiment at the same time. As previously done, we are going to get the current model form the production line and we are opening two new branches. Branch1 and Branch2.

In branch one we are going to add a new feature, Automatic mirror, in the other Branch, we are going to work on a separate feature called “dark mirror”.

After some time spent in Branch one, we have decided to merge the work back into the main product line. As with our previous example, there is no issue because no one has worked on any feature on this car that affected the mirror ( or at least not in master).

Development on the second branch has now completed and we want to merge the second branch in master. Unfortunately, when trying to merge this new feature in the main production line, we have a “merge conflict”. There are two parts on the same production line that try to change the mirror. One wants to add automatic mirrors and the other wants to make it black. To solve this issue the engineer need to manually decide which feature he wants to keep between the different branches. In our case the Engineer has decided to keep both and will solve the conflict by adding both feature in the main production line.



In the above article I have just touched slightly some of the most used commands and terms that are use when using a version control. Using a Version Control software is like driving a car, initially it seems impossible, and everything is extremely hard, but then it becomes muscle memory and it is straight forward.

Unfortunately for me, this is the case now, and it is extremely hard trying to put even simple task in words. I thought this article would be easy for me, but it turned out to be one of the hardest.

If any of you know how to explain this in better terms or has comment of question please do not hesitate to comment below and I will happily edit the article to make it better.


*  Version Control definition from website:






Write cleaner Javascript code with Eslint

Javascript has a bad reputation, and this is mainly due to the fact that it is too flexible to use. Many users would abuse this great feature of this language writing code that is very inconsistent and hard to follow. For example, simple inconsistency like single or double quote around strings, can make project seem quite unclear and messy.

In recent years, after I have been exposed to different languages that follow a more rigid approach to coding standards, I have started to focus to write cleaner Javascript, and I would like to share some of these experiences.

JavaScript, is especially prone to developer error due to its lack of a compilation process. Linting tools allow developers to discover problems with their JavaScript code without the need of executing it. In this article I will be going into details on how you can  use and configure a lint utility to support you.

What is Eslint

Eslint is a pluggable linting utility created by Nicholas Zokas in June 2013, that can be used to analyse our Javascript code to highlight errors on the fly, supporting a quick and clean development.

There are many linters around, but I am listing below some of the reasons that have supported my decision to choose Eslint:

  • It is open source.
  • Great documentation.
  • Huge number of configurations
  • Good examples
  • Works with all major IDE and Code editors.
  • Can be used from the Command Line
  • Works on Build Server

Getting started with Eslint

Eslint requires Node,js to be installed on your machine, so if you do not have it, please download the latest stable release from the main website.


After Node.js is up and running, we can move to the next step by opening a Command Prompt and installing the Eslint package from NPM (visit the NPM website for more information regarding its usage).

Install eslint package globally
  1. npm i -g eslint


Following the installation above, we now have to define a configuration file called .eslintrc.json. Eslint comes with an handy feature to support you in creating this file. To trigger it, access the root location of your site and type the following command

Create eslint config file
  1. eslint --init

This command will return three options:

  1. Ask a couple of questions to define the configuration required
  2. Use a popular styleguide ( this will require an existing NPM package)
  3. Inspect your Javascript Files (not suggested if your coding style is inconsistent)

The above will be displayed in the command prompt like shown by the image below:

eslint --init options

For the purpose of this blog post, I am going to provide my own configuration file that need to be extracted in the root of your site. The file can be downloaded by clicking the following link:

Eslint Configuration File

Run the linter

After successfully complete the above steps, you will now be able to use Eslint by using its extensive CLI (command line interface) commands or within most of the major IDE (mode details to follow). The most basic command would just include the file or path to test, for example the following two example will respectively test file.js and all files within the “site” folder

eslint run
  1. eslint "c:/site/file.js"
  2. eslint "c:/site"

Configuration File explained

Now that we have Eslint fully configured, it is time to dive into the configuration file to see how a configuration file is structured, and what configurations are set in our setup. As mentioned above, there are hundreds of configurations, all well documented on the Eslint website.

Root & Environments

Section one
"root": true, //this will set this file and folder as the root directoty
    "env": {//load common environment/plugin configuration
        "browser": true,
        "commonjs": true,
        "es6": true,
        "node": true,
        "jquery": true

The first section of our configuration file includes the root setting. This is an optional setting that define the root of your project. Projects can have more than one Eslint configuration file, and when running it, it will search in the current folder and all its ancestors until it finds the root value.

The next setting used is the env (environment). Using this setting will load specific environment setting. For example in the case above we are allowing the use of ES6 notation, therefore we would not have any error triggered if using the arrow notation =>.


Globals eslint
"globals": {
        "exampleGlobalVariableName": true

The global configuration accept a object that will determine global variables that we can use within our JS files, without the need to be declared. Failing to do so, will trigger a no-undef error.

For example, when we added jQuery in the env setting above, has indirectly set a global for $ and jQuery variables. This setting is really useful to support the user to understand unexpected dependencies that you may have, that will result in hard unit testing.


Most of the configuration have three simple settings.

  • off – This configuration is self explanatory. It will switch the error off.
  • warn – This setting will trigger a Warning error. In many IDE warning are displayed with a Yellow underline.
  • error – This setting will return an error. A file could have some warning, but you should always aim for “error free” files.

Some specific rules have more arguments that can be used, but I will be wasting time trying to explain them, as the Eslint documentation is really complete.

Using Code Editors

Eslint CLI is fantastic, but I do not expect you to run it every single time you modify a file, and even if the linter gives you the line number for it, it would still be hard to use on a daily basis.

Luckily for us, Eslint is very easy to set up in most of the major code editors. In this section of the article, I am going to show how you install the linted on Visual Studio Code, that is my editor of choice.

Visual Studio Code

To use Eslint in the editor, we need to first install the official extension called ESlint. To access the extension page click the Extension button on the left menu or click Ctrl+ Shift + X (on windows).

After installing the above extension, you will be required to restart the editor for the effect to take place.

On restart, assuming your Eslint configuration file is in the correct folder, you will be able to immediately see errors highlighted in real time.

The screen shots below show some of the feature available when enabling the extension.



I have personally doubt the need for a tool like this, but now after using it, I cannot live without. The configuration that I have shared is a personal choice and I am more than happy for you to use it if you wish to, but at the same time, you should also dive into the available rules and see if there is anything that fit your guidelines.

Start to use a linter is just the first step to write cleaner code. No matter if you are a single developer or work in a big team. Introducing this tool will increase the quality and readability of your code. We have all been guilty of being sometimes lazy to keep our project consistent and lacking structure, but now the tools are available and we have no excuse but to start and write cleaner Javascript.