#codestyle

Programming goes beyond the super-nerd concept of “writing code for a machine”.

Yes, it’s the hard truth but, today, writing code is also a social display of respect.

Respect for you as developer, respect for your team.

Quoting this interesting post:

“Write code for your later self and for your co-workers in the first place - not for the machine”  - @RisingStack

Writing one-line, chained statements full of language (and unreadable) tricks quickly becomes no more than a vain practice, when reiterated.

Thus, in case of medium and large codebases, adopting a shared code styling actually becomes mandatory. Enabling all the developers in your team to be able to read the code each other developer writes is another safe practice (referring to the Modern Agile’s “Make Safety a Prerequisite” concept).

Using in your development workflow a linter plus a shared code style (enforced by automatic rules) helps in making your code more safe, less error-prone and more readable by developers.

Some examples of what a linter + code styling can enforce are: avoiding variables usage before their declarations, avoiding not used variables, avoiding suspicious or not guarded for loops, avoiding to long lines, avoiding missing semicolons, and so on…

Talking about JavaScript, ESLint is a very nice pluggable linting utility for that programming language.

Configuring and using ESLint allows developers to check their code before execution, at writing-time. ESLint, thanks to its extendible set of common rules, makes the work for you. It can be used as a command-line tool and becomes really useful when plugged in your preferred IDE, which visually remarks all the issues related to linting your code.

For example, in the following picture we can see Visual Studio Code IDE showing some issues about our code, in particular: suggesting to use const instead of var and rising a code style exception in using spaces inside parens.

The other aspect is Code Styling. Code styling refers to code conventions and how to write it. For example: using semicolons or not, naming conventions for variables and functions (camel-case or Pascal-case?), named function expressions instead of function declarations, code lines length, how many spaces in tabs and so on…

A nice (and very used) code styling is the one adopted and published by AirBnB team, have fun exploring it!

The cool thing is that they provide a set of plugins for ESLint in order to use them in your code, simply configuring the latter.

In a very pragmatic way, starting using ESLint + AirBnB Code Style in a Node.js project means:

1.  Installing ESLint and AirBnB plugins as dev dependencies:

"devDependencies": { ... "eslint": "^3.19.0", "eslint-config-airbnb-base": "^11.1.3", "eslint-plugin-import": "^2.2.0", "eslint-plugin-mocha": "^4.9.0", ... },

2.  creating the .eslintrc.json ESLint configuration file in your project root directory (your IDE will use it)

A possible configuration (we are using) can be the following:

{ "extends": "airbnb-base", "plugins": [ "import", "mocha"], "rules": { "no-console": "off", "no-restricted-syntax": "off", "no-shadow": ["error", { "allow": ["done", "resolve", "reject", "done", "cb", "callback", "err", "req", "res"] }], "mocha/no-exclusive-tests": "error" } }

As depicted in the previous snippet, we overrode some rules. For example there we are telling ESLint to allow the JS console usage, to allow variables shadowing only for done, resolve, reject, cb, etc…

We’re also using the mocha plugin in order to instruct ESLint about allowing particular functions like describe(), it(), and so on...

Among other issues, using the linter we quickly:

discovered a lot of language tricks (i.e. !!, Boolean(), …);

discovered a lot of not-required statements and conditional checking;

discovered a lot of undeclared variables;

improved code readability;

Avoided verbose syntactic sugar;

Discovered a lot of missing or unnecessary semicolons;

...and lot of other things!

In this post we remarked the power of a code style adoption:  to catch bugs at writing time and to converge on a shared code styling in the development team, allowing people to write more readable code, simplifying collaboration and codebase maintenance. 

http://jshint.com/

http://eslint.org/demo/

PS bonus points for naming your style guide if you conform to one too...