Minimize bad codes on your javascript project

Deni Putra Perdana
SkyshiDigital
Published in
3 min readFeb 27, 2017

When you are working on a team that consist of 2 or more people from small to big teams, you will find that not every person coded the same way you code, everyone has their own code style and maybe magic code.

Or in a different case like working on your own, you will find your one month old code unreadable by yourself, yes programmers are often upgrading their skills (including their code style), in the end you will find your code hard to understand by other people, and even yourself. If you find yourself in this position maybe it’s time to pick one of javascript style guide or create one yourself.

Selecting Style Guide

There’s plenty style to pick, don’t bother to create one yourself, and they supported by the big and expanding javascript community sorted by most stars on github:

1. airbnb/javascript

A mostly reasonable approach to JavaScript. Created, used and maintained by airbnb team.

2. feross/standard

One JavaScript Style to Rule Them All. Used by npm, mongodb, atom and github itself! Created by Feross Aboukhadijeh.

3. felixge/node-style-guide

This is a guide for writing consistent and aesthetically pleasing node.js code. It is inspired by what is popular within the community, and flavored with some personal opinions. You can fork customize this as your own style. Created by Felix Geisendörfer.

4. bevacqua/js

This style guide aims to provide the ground rules for an application’s JavaScript code, such that it’s highly readable and consistent across different developers on a team. The focus is put on quality and coherence across the different pieces of your application. Created by Nicolás Bevacqua.

Personally I used standard.js for my projects because of

One JavaScript Style Guide to Rule Them All.

However, the rules are simple:

· 2 spaces — for indentation

· Single quotes for strings — except to avoid escaping

· No unused variables — this one catches tons of bugs!

· No semicolonsIt’s fine. Really!

· Never start a line with (, [, or `

o This is the only gotcha with omitting semicolons — automatically checked for you!

o More details

· Space after keywords if (condition) { … }

· Space after function name function name (arg) { … }

· Always use === instead of == — but obj == null is allowed to check null || undefined.

· Always handle the node.js err function parameter

· Always prefix browser globals with window — except document and navigator are okay

· Prevents accidental use of poorly-named browser globals like open, length, event, and name.

· And more goodnessgive standard a try today!

To install standard.js, simply:

npm install standard — save-dev

To use it, type standard on your root project directory

standard.js error

When there’s no error like one on the example, don’t worry! you are good to go!

If you want to explore more about standard go to http://standardjs.com or navigate to their github page.

After selecting style guide, now what?

It’s time to configure git-hooks

Git-what??

What are Git hooks?

Git hooks are scripts that Git executes before or after events such as: commit, push, and receive. Git hooks are a built-in feature — no need to download anything. Git hooks are run locally.

source

For the javascript githooks we are using Husky. Why? Because

Husky can prevent bad commit, push and more 🐶 woof!

To install Husky, simply:

npm install husky — save-dev

and then on packages.json insert this on scripts

...
{
"scripts": { "lint": "standard --verbose | snazzy", "precommit": "npm run lint", "...": "..." }}
...

explanations:

· lint: when we run npm run lint the npm runs standard.js checking

· precommit: command that run before you commited on your git repository. It’s used by husky (and other git hooks package). more about this

How do we use it?

Simply change one of your code, and commit to the repo

Failed pre-commit

Voila! Now your code (and your team code) are checked before they commited to the repo!

Profit!

--

--