Giters

andrevvalle / my-coding-style

My own coding conventions for JavaScript development :zap:

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

My Coding Style

For years I've been using different coding conventions for JavaScript development.

But after reading Nicholas Zakas's book and inspired by @zeh, I've decided to formalize my reasons behind some of the conventions I adopted. Feel free to suggest anything you want :)

"All code in any code-base should look like a single person typed it, no matter how many people contributed."

Commits

Every commit message, pull request title or issue discussion must be in English.

Reason: English is the universal language nowadays, if you use any other language you're excluding potencial contributors.

Don't use Past or Present Continuous tenses for commit messages, those should be in Imperative Present tense.

// Good
Add feature X

// Bad
Added feature X
Adding feature X

Reason: This preference comes from Git itself.

When releasing a new version, write a commit message in the following format "Release - v1.0.0" instead of "v1.0.0".

Reason: Makes it easier to track version releases in git history. For example, you could run git log --pretty=format:"%H %s" | grep 'Release' to fetch only version bump commits.

Indentation

The unit of indentation is 4 spaces. Never mix spaces and tabs.

// Good
while (condition) {
    statements
}

// Bad
while (condition) {
  statements
}

Reason: TODO

Line length

Avoid lines longer than 100 characters. When a statement will not fit on a single line, it may be necessary to break it. Place the break after an operator, ideally after a comma. The next line should be indented 4 spaces.

// Good
YUI().use('aui-module-a', 'aui-module-b', 'aui-module-c', 'aui-module-d',
    'aui-module-e', 'aui-module-f');

// Bad
YUI().use('aui-module-a', 'aui-module-b', 'aui-module-c', 'aui-module-d', 'aui-module-e', 'aui-module-f');

Every project should contain a .editorconfig file that automatically set some indentation definitions. Make sure to install Editor Config's plugin on your code editor and you'll be all set.

Reason: TODO

Linting

Use JSHint to detect errors and potential problems.

The options for JSHint are stored in a .jshintrc file.

Reason: TODO

Semicolons

Relying on ASI (Automatic Semicolon Insertion) can cause hard to debug problems, so don't do it. Always use semicolons.

// Good
a = b + c;
test();

// Bad
a = b + c
test()

Reason: TODO

Variables

All variables should be declared before used. Avoid multiple var statements.

// Good
var foo = '',
    bar = '';

// Bad
var foo = '';
var bar = '';

Constants (variables with permanent values) are written uppercase.

// Good
var FOO = 'foo';

// Bad
var foo = 'foo';

Reason: TODO

Strings

Prefer single quotes over double quotes.

// Good
var string = '<p class="foo">Lorem Ipsum</p>';

// Bad
var string = "<p class='foo'>Lorem Ipsum</p>";

Hexidecimal colors are written uppercase.

// Good
var color = '#D96AB6';

// Bad
var color = '#d96ab6';

Reason: TODO

New lines

Parentheses () and commas , are not followed by indented children on new lines.

// Good
YUI().use('aui-module', function (Y) {
    statements
});

// Bad
YUI().use(
    'aui-module',
    function (Y) {
        statements
    }
);

Curly brackets {} are followed by new lines and indented children.

// Good
if (condition) {
    statements
}
else {
    statements
}

// Bad
if (condition) {
    statements
} else {
    statements
}

Reason: TODO

Whitespace

Add spaces between operators (=, >, *, etc).

// Good
for (i = 0; i < 10; i++) {
    statements
}

// Bad
for (i=0;i<10;i++) {
    statements
}

Both function expressions and function declarations doesn't have a space between the function keyword and the function name.

// Good
var foo = function() {
    statements
};

// Bad
var foo = function () {
    statements
};

// Good
function bar() {
    statements
}

// Bad
function bar () {
    statements
}

Add spaces outside parentheses () but avoid it inside.

// Good
if (x > 10) {
    statements
}

// Bad
if( x > 10 ){
    statements
}

Empty lines have no trailing spaces.

Reason: TODO

Conditionals

Avoid inline conditionals. Every conditional (with single or multiple statements) should use curly brackets {}. The only exception to this rule is else if.

// Good
if (condition) {
    statements
}
else if (condition) {
    statements
}
else {
    statements
}

// Bad
if (condition) statement;
else if (condition) statement;
else statement;

Reason: TODO

Equality

Strict equality checks === should be used in favor of ==.

// Good
if (foo === 'foo') {
    statement
}

// Bad
if (foo == 'foo') {
    statement
}

// Good
if (bar !== 'bar') {
    statement
}

// Bad
if (bar != 'bar') {
    statement
}

Reason: TODO

Loops

Avoid inline loops. Every loop (with single or multiple statements) should use curly brackets {}.

// Good
for (initialization; condition; expression) {
    statements
}

// Bad
for (initialization; condition; expression) statement;

Reason: TODO

References

License

MIT License © Zeno Rocha

About

My own coding conventions for JavaScript development :zap: