JavaScript Code Style

This is a guide for writing consistent and aesthetically pleasing JavaScript code. It is inspired by what is popular within the community, and flavored with some personal opinions.

Objects

Use the literal syntax for object creation.

Both ways do the same thing, but literal notation takes less space. It's clearly recognizable as to what is happening, so using new Object(), is really just typing more.

// bad
var item = new Object();

// good
var item = {};

Don't use reserved words as keys.

It won't work in IE8.

// bad
var superman = {
        default: {clark: 'kent'},
        private: true
    };

// good
var superman = {
        defaults: {clark: 'kent'},
        hidden: true
    };

Use readable synonyms in place of reserved words.

// bad
var superman = {
        klass: 'alien'
    };

// good
var superman = {
        type: 'alien'
    };

for-in loop should be used only for iterating over keys in an object/map/hash.

Such loops are often incorrectly used to loop over the elements in an Array. This is however very error prone because it does not loop from 0 to length - 1 but over all the present keys in the object and its prototype chain.

// only for objects (not arrays)
for ( var key in someObject ) {
    if ( someObject.hasOwnProperty(key) ) {
        console.log(someObject[key]);
    }
}

Modifying prototypes of builtin objects should be avoided.

Modifying builtins like Object.prototype and Array.prototype are forbidden. Modifying other builtins like Function.prototype is less dangerous but still leads to hard to debug issues in production and should be avoided.

Arrays

Use the literal syntax for array creation.

new Array(len) creates an array with len holes. On some JavaScript engines, this operation lets you pre-allocate arrays, giving you performance benefits for small arrays (not for large ones). In most cases, performance doesn’t matter and you can avoid the redundancy introduced by a preallocation. If it fits the problem, an array literal initializing all elements at once is preferable.

// bad
var items = new Array();

// good
var items = [];

To append some value to array use Array.push or direct access.

items[items.length] = 'abracadabra';
itmes.push('abracadabra');

When you need to copy an array use Array.slice.

itemsCopy = items.slice();

To convert an array-like object to an array, use it as well.

function trigger() {
    var args = Array.prototype.slice.call(arguments);
    // ...
}

Use simple iteration for big data. forEach approach looks better but good only for small arrays.

Anonymous iteration function call has a small cost but multiplied by millions gives bad results.

// good for large arrays
var length = someArray.length,
    index;

for ( index = 0; index < length; index++ ) {
    console.log(someArray[index]);
}

// good for small arrays
someArray.forEach(function ( item ) {
    console.log(item);
});

There is also an alternative way to iterate arrays.

It's more compact and has about the same speed as simple forEach.

var length = someArray.length;

while ( length-- ) {
    console.log(someArray[length]);
}

Strings

Use single quotes '' for strings.

The difference between single and double quotes is that you don't need to escape single quotes in double quotes, or double quotes in single quotes. That is the only difference, if you do not count the fact that you must hold the Shift key to type ".

// bad
var name = "Bob Parr",
    fullName = "Bob " + this.lastName;

// good
var name = 'Bob Parr',
    fullName = 'Bob ' + this.lastName;

Strings longer than 100 characters should be written across multiple lines using string concatenation.

In general use of such long lines should be avoided. If overused, long strings with concatenation could impact performance. jsPerf & Discussion.

// good
var errorMessage = 'Lorem ipsum dolor sit amet, consectetur adipisicing elit, \
sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. \
Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris.';

// also good
var errorMessage = 'Lorem ipsum dolor sit amet, consectetur adipisicing elit, ' +
'sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. ' +
'Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris.';

When programatically building up complicated strings, use Array.join. String concatenation is good for simple cases.

Modern browsers are optimized to do string concatenations so performance is not an issue anymore.

// good
var someText = '',
    index;

for ( index = 30000; index > 0; index-- ) {
    someText += 'String concatenation. ';
}

// also good
var someText  = '',
    someArray = [],
    index;

for ( index = 30000; index > 0; index-- ) {
    someArray.push('String concatenation.');
}

someText = someArray.join(' ');

Functions

Function expressions:

// anonymous function expression
var anonymous = function () {
        return true;
    };

// named function expression
var named = function named () {
        return true;
    };

// immediately-invoked function expression (IIFE)
(function () {
    return true;
})();

Never declare a function in a non-function block (if, while, etc).

Assign the function to a variable instead. Browsers will allow you to do it, but they all interpret it differently.

// bad
if ( currentUser ) {
    function test () {
        console.log('Nope.');
    }
}

// good
var test;

if ( currentUser ) {
    test = function test () {
        console.log('Yup.');
    };
}

Never name a parameter arguments.

This will take precedence over the arguments object that is given to every function scope.

// bad
function nope ( name, options, arguments ) {
    // ...
}

// good
function yup ( name, options, args ) {
    // ...
}

When possible, all function arguments should be listed on the same line. If doing so would exceed the 100-column limit, the arguments must be line-wrapped in a readable way. To save space, you may wrap as close to 100 as possible, or put each argument on its own line to enhance readability. The indentation may be either one tab, or aligned to the parenthesis.

// works with very long function names, survives renaming without reindenting
some.name.space.withSomeVeryLongFunctionName = function (
    veryLongArg1, veryLongArg2,
    veryLongArg3, veryLongArg4 ) {
    // ...
};

// one argument per line, survives renaming and emphasizes each argument
some.name.space.withSomeVeryLongFunctionName = function (
    veryLongArg1,
    veryLongArg2,
    veryLongArg3,
    veryLongArg4 ) {
    // ...
};

// visually groups arguments
function test ( veryLongArg1, veryLongArg2,
                veryLongArg3, veryLongArg4 ) {
    // ...
}

// parenthesis-aligned, one emphasized argument per line
function test ( veryLongArg1,
                veryLongArg2,
                veryLongArg3,
                veryLongArg4 ) {
    // ...
}

A function should have a singular purpose that is easily defined. Its size can vary but try to keep it in about 30-50 lines.

Properties

Use dot notation when accessing properties wherever possible.

Dot notation is faster to write and clearer to read. Square bracket notation allows access to properties containing special characters and selection of properties using variables.

// bad
var data = items['pear'];

// good
var data = items.pear;

// also good
var name = 'pear',
    data = items[name];

Delete properties with assigning to null.

In modern JavaScript engines, changing the number of properties on an object is much slower than reassigning the values. The delete keyword should be avoided except when it is necessary to remove a property from an object's iterated list of keys, or to change the result of if ( key in someObject ).

// think twice
Foo.prototype.dispose = function () {
    delete this.someProperty;
};

// good in most cases
Foo.prototype.dispose = function () {
    this.someProperty = null;
};

Variables

Always use var to declare variables.

When you fail to specify var, the variable gets placed in the global context, potentially clobbering existing values. Also, if there's no declaration, it's hard to tell in what scope a variable lives (e.g., it could be in the Document or Window just as easily as in the local scope). So always declare with var.

// bad
superPower = new SuperPower();

// good
var superPower = new SuperPower();

Use one var declaration for multiple variables in each scope.

// bad
var items   = getItems();
var isFresh = true;
var topHtml = 'z';

// good
var items   = getItems(),
    isFresh = true,
    topHtml = 'z';

Declare unassigned variables last.

This is helpful when later on you might need to assign a variable depending on one of the previous assigned variables.

// bad
var i, len,
    items = getItems(),
    goSportsTeam = true,
    dragonball;

// good
var items = getItems(),
    goSportsTeam = true,
    dragonball, length, index;

Group your vars by meaning and try to align them.

var // system modules
    fs    = require('fs'),
    path  = require('path'),
    // external dependencies
    ws    = require('ws'),
    ssh2  = require('ssh2'),
    // local modules
    utils = require('../lib/utils'),
    keys  = require('../keys'),
    // vars with values
    items = [],
    goods = {},
    maps  = null,
    topMarks  = [5,6,7],
    topGrades = [56,57,58],
    topCars   = null,
    // all best categories
    bestBooks, bestFilms, bestSongs,
    // everything about customer
    customerTickets, customerLogin, customerLinks,
    // DOM nodes
    $panel, $button;

Assign variables at the top of their scope.

This helps avoid issues with variable declaration and assignment hoisting related issues.

// bad
function nope () {
    test();

    // ...

    var name = getName();

    if ( name === 'test' ) {
        return false;
    }

    return name;
}

// good
function yep () {
    var name = getName();

    test();

    // ...

    if ( name === 'test' ) {
        return false;
    }

    return name;
}

// bad
function nope () {
    var name = getName();

    if ( !arguments.length ) {
        return false;
    }

    // ...

    return true;
}

// good
function yep () {
    var name;

    if ( !arguments.length ) {
        return false;
    }

    name = getName();

    // ...

    return true;
}

Separate variable declaration from code. This will improve readability.

// bad
function hasName () {
    var name = getName();
    name = name.trim();
    return name !== '';
}

// good
function hasName () {
    var name = getName();

    name = name.trim();
    
    return name !== '';
}

In complex cases use JavaScript native approach.

Variable and function declarations get hoisted to the top of their scope, their assignment does not. For more information refer to JavaScript Scoping & Hoisting

// bad
function nope ( isReady ) {
    if ( !isReady ) {
        return;
    }

    var name = getName(),
        a, b, c;

    // ...
}

// also bad
function nope ( isReady ) {
    var name = getName(),
        a, b, c;

    if ( !isReady ) {
        return;
    }

    // ...
}

// good
function yep ( isReady ) {
    var name, title, info, data;

    if ( !isReady ) {
        return;
    }

    name = getName();

    // ...
}

Conditional Expressions & Equality

Use === and !== over == and !=.

This helps to maintain data type integrity throughout your code and has a better performance. For more information see Truth Equality and JavaScript.

Conditional expressions are evaluated using coercion with the ToBoolean method and always follow these simple rules:

Objects evaluate to true
Undefined evaluates to false
Null evaluates to false
Booleans evaluate to the value of the boolean
Numbers evaluate to false if +0, -0, or NaN, otherwise true
Strings evaluate to false if an empty string '', otherwise true

Use simple single if for complex expressions.

// bad
if ( a === 1 ) {
    if ( b === 2 ) {
        if ( a1 === 1 ) {
            if ( b1 === 2 ) {
                c = 1;
            }
        }
    }
}

// also bad
(a === 1) && (b === 2) && (a1 === 1) && (b1 === 2) && (c = 1);

// good
if ( a === 1 && b === 2 && a1 === 1 && b1 === 2 ) {
    c = 1;
}

In case your control statement (if, while etc.) gets too long or exceeds the maximum line length, each (grouped) condition could be put into a new line. The logical operator should begin the line.

// good
if (
    (someVariableA === 1 || someVariableB === 2)
    && isSomethingVisible()
    && isSomethingActive()
) {
    go();
}

Blocks

Always use braces with all blocks.

// bad
if ( isReady )
    return true;

// bad
if ( isReady ) return true;

// good
if ( isReady ) {
    return true;
}

Because of implicit semicolon insertion, always start your curly braces on the same line as whatever they're opening.

// bad
if ( something )
{
    // ...
}
else
{
    // ...
}

// good
if ( something ) {
    // ...
} else {
    // ...
}

with ( someVar ) { ... } should be avoided.

Using with clouds the semantics of your program. Because the object of the with can have properties that collide with local variables, it can drastically change the meaning of your program.

Comments

Use // (with a trailing space) for both single line and multi line comments. Try to write comments that explain higher level mechanisms or clarify difficult segments of your code. Don't use comments to restate trivial things.

//bad

/////// also bad

// good

// good
// when there is a lot to comment

// also good
var active  = true,   // this var description
    single  = false,  // another var description
    isReady = false;  // and one more

For var/function/class declarations JSDoc should be used.

Use //FIXME: to annotate problems.

Helps other developers quickly understand if you're pointing out a problem that needs to be revisited.

function build () {
    //FIXME: shouldn't use a global here
    total = 0;
}

Use //TODO: to annotate solutions to problems.

Helps other developers to see if you're suggesting a solution to the problem that needs to be implemented.

function build () {
    //TODO: total should be configurable by an options param
    this.total = 0;
}

Whitespaces

Use 4 space characters for one-level indentation.

// bad
function test () {
∙∙var name;
}

// bad
function test () {
⇥var name;
}

// good
function test () {
∙∙∙∙var name;
}

No whitespace at the end of line or on blank lines.

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

// bad
if ( a>5 && b*8<345 ) { c=true; }

// good
if ( a > 5 && b * 8 < 345 ) { c = true; }

Unary special-character operators (e.g., !, ++) must not have space next to their operand.

// bad
if ( ! isReady ) { ... }

// good
if ( !isReady ) { ... }

Any , and ; must not have preceding space.

// bad
someCall(a , b , c) ;

// good
someCall(a, b, c);

Any ; used as a statement terminator must be at the end of the line.

Any : after a property name in an object definition must not have preceding space.

// bad
var someObject = {a : 1, b : 2, c : 3};

// good
var someObject = {a: 1, b: 2, c: 3};

The ? and : in a ternary conditional must have space on both sides.

// bad
var flag = isReady?1:0;

// good
var flag = isReady ? 1 : 0;

// also good for long expressions
var flag = isReady
    ? someVeryLongEvaluatedOrSomethingElseValue
    : anotherVeryLongEvaluatedOrSomethingElseValue;

No spaces in empty constructs like {}, [].

Place one space before the leading brace.

// bad
function test(){
    // ...
}

// bad
dog.set('attr',{
    age: '1 year',
    breed: 'Bernese Mountain Dog'
});

// good
function test () {
    // ...
}

// good
dog.set('attr', {
    age: '1 year',
    breed: 'Bernese Mountain Dog'
});

Separate function name and its parameters in declaration.

// bad
function test(){
    // ...
}

// bad
function test(a, b){
    // ...
}

// good
function test ( a, b ) {
    // ...
}

// but no leading/trailing spaces on execution
test(128, 'qwe');

The same for if, if/else, switch, try/catch blocks.

// bad
if(isReady){
    // ...
}

// bad
try{
    // ...
}catch(e){
    // error handling
}

// good
if ( isReady ) {
    // ...
}

// good
try {
    // ...
} catch ( e ) {
    // error handling
}

Place an empty newline at the end of a file.

Each line should be terminated with a newline character, including the last one. Some programs have problems processing the last line of a file if it isn't newline terminated.

Use line breaks and indentation when making long method chains.

// bad
$('#items').find('.selected').highlight().end().find('.open').updateCount();

// good
$('#items')
    .find('.selected')
        .highlight()
        .end()
    .find('.open')
        .updateCount();

Single-line array and object initializers are allowed when they fit on a line.

var someArray  = [1, 2, 3];           // No space after [ or before ].
var someObject = {a: 1, b: 2, c: 3};  // No space after { or before }.

Use newlines to group logically related pieces of code.

doSomethingTo(x);
doSomethingElseTo(x);
andThen(x);

nowDoSomethingWith(y);

andNowWith(z);

Commas

No Leading commas.

// bad
var once
    , upon
    , aTime;

// bad
var hero = {
    firstName: 'Bob'
  , lastName: 'Parr'
  , heroName: 'Mr. Incredible'
  , superPower: 'strength'
};

// good
var once,
    upon,
    aTime;

// good
var hero = {
        firstName:  'Bob',
        lastName:   'Parr',
        heroName:   'Mr. Incredible',
        superPower: 'strength'
    };

No Additional trailing comma.

This can cause problems with IE6/7 and IE9 if it's in quirksmode. Also, in some implementations of ES3 would add length to an array if it had an additional trailing comma. This was clarified in ES5.

// bad
var hero = {
        firstName: 'Kevin',
        lastName: 'Flynn',
    };

// bad
var heroes = [
        'Batman',
        'Superman',
    ];

// good
var hero = {
        firstName: 'Kevin',
        lastName: 'Flynn'
    };

// good
var heroes = [
        'Batman',
        'Superman'
    ];

Semicolons

Semicolons use is mandatory.

Relying on ASI (Automatic Semicolon Insertion) can cause subtle, hard to debug problems.

// bad
a = b + c
test()

// bad
(function () {
    var name = 'Skywalker'
    return name
})()

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

// good
(function() {
    var name = 'Skywalker';
    
    return name;
})();

Semicolons should be included at the end of function expressions, but not at the end of function declarations.

var foo = function () {
        return true;
    };  // semicolon here

function foo () {
    return true;
}  // no semicolon here

Type Casting & Coercion

Perform type coercion at the beginning of the statement.

// bad
var totalScore = intValue + '';

// bad
var totalScore = '' + intValue + ' total score';

// good
var totalScore = '' + intValue;

// good
var totalScore = intValue + ' total score';

Use parseInt for Numbers and always with a radix for type casting.

var inputValue = '4';

// bad
var value = new Number(inputValue);

// bad
var value = +inputValue;

// bad
var value = inputValue >> 0;

// bad
var value = parseInt(inputValue);

// good
var value = Number(inputValue);

// good
var value = parseInt(inputValue, 10);

Booleans.

var age = 0;

// bad
var hasAge = new Boolean(age);

// good
var hasAge = Boolean(age);

// good
var hasAge = !!age;

Naming Conventions

Names should be descriptive but not excessively so. Avoid use of international characters, uncommon abbreviations and single letter names. Avoid combining full and abbreviated words in names.

// bad
var arrLen = 0;

function q () {
    // ...
}

// good
var arrayLength = 0;

function query () {
    // ...
}

Use lowerCamelCase when naming objects, functions, and instances.

// bad
var OBJEcttsssss = {};
var this_is_my_object = {};
function c() {};
var u = new user({
    name: 'Bob Parr'
});

// good
var thisIsMyObject = {},
    user = new User({
        name: 'Bob Parr'
    });

function thisIsMyFunction () {
    // ...
}

Use PascalCase when naming constructors or classes.

// bad
function user ( options ) {
    this.name = options.name;
}

var bad = new user({
        name: 'nope'
    });

// good
function User ( options ) {
    this.name = options.name;
}

var good = new User({
        name: 'yup'
    });

If a value is intended to be constant and immutable, it should be given a name in CONSTANT_VALUE_CASE.

var SECOND = 1 * 1000;
this.TIMEOUT_IN_MILLISECONDS = 60;

Use a leading underscore _ when naming private properties.

// bad
this.__firstName__ = 'Panda';
this.firstName_ = 'Panda';

// good
this._firstName = 'Panda';

When saving a reference to this use self or a corresponding meaningful name.

// bad
function foo () {
    var that = this;

    return function () {
        console.log(that);
    };
}

// good
function foo () {
    var self = this;

    return function () {
        console.log(self);
    };
}

// also good
function foo () {
    var parentFunc = this;

    return function () {
        console.log(parentFunc);
    };
}

Name your functions.

This will produce better stack traces, heap and CPU profiles.

// bad
getData(function ( data ) {
    console.log(data);
});

// good
getData(function getDataCallback ( data ) {
    console.log(data);
});

Use leading $ to indicate that a DOM node is assigned to variable or property.

// bad
var body = document.querySelector('div.page');

this.$shadow = {
    left: document.createElement('div'),
    right: document.createElement('div')
};

// good
var $body = document.querySelector('div.page'),
    $text = document.createTextNode('something awesome');

this.shadows = {
    $left: document.createElement('div'),
    $right: document.createElement('div')
};

Use dot as a separator for file names. Only lowercase allowed in order to avoid confusion on case-sensitive platforms. File names should contain no punctuation.

// bad
modelmain.js
modelMain.js
ModelMain.js
model_main.js
model-main.js
model main.js

// good
model.main.js

Accessors

Getters and setters methods for properties are not strictly required. If you do make accessor functions use getVal() and setVal('hello'). It’s okay to create get() and set() functions, but be consistent.

// bad
dragon.age();    // getter
dragon.age(25);  // setter

// good
dragon.getAge();
dragon.setAge(25);

If the property is a boolean, use isVal() or hasVal().

// bad
if ( !dragon.age() ) {
    return false;
}

// good
if ( !dragon.hasAge() ) {
    return false;
}

Constructors

Assign methods to the prototype object, instead of overwriting the prototype with a new object.

Overwriting the prototype makes inheritance impossible: by resetting the prototype you'll overwrite the base!

function Jedi () {
    console.log('new jedi');
}

// bad
Jedi.prototype = {
    fight: function fight () {
        console.log('fighting');
    },

    block: function block () {
        console.log('blocking');
    }
};

// good
Jedi.prototype.fight = function fight () {
    console.log('fighting');
};

Jedi.prototype.block = function block () {
    console.log('blocking');
};

Methods can return this to help with method chaining.

// bad
Jedi.prototype.jump = function () {
    this.jumping = true;
    return true;
};

Jedi.prototype.setHeight = function ( height ) {
    this.height = height;
};

var luke = new Jedi();
luke.jump(); // => true
luke.setHeight(20) // => undefined

// good
Jedi.prototype.jump = function () {
    this.jumping = true;
    return this;
};

Jedi.prototype.setHeight = function ( height ) {
    this.height = height;
    return this;
};

var luke = new Jedi();

luke.jump()
    .setHeight(20);

It's okay to write a custom toString() method, just make sure it works successfully and causes no side effects.

function Jedi ( options ) {
    options = options || {};
    this.name = options.name || 'no name';
}

Jedi.prototype.getName = function getName () {
    return this.name;
};

Jedi.prototype.toString = function toString () {
    return 'Jedi - ' + this.getName();
};

Events

When attaching data to events it's always should be only one parameter. Pass a hash instead of a raw value in case there are more then one parameter.

This approach allows EventEmitter implementation with better performance.

// bad
button.trigger('click', data1, data2, data3);

button.on('click', function ( data1, data2, data3 ) {
    // do something with arguments
});

// good
button.trigger('click', value);

button.on('click', function ( value ) {
    // do something with value
});

// good
button.trigger('click', {val1: data1, val2: data2, val3: data3});

button.on('click', function ( data ) {
    // do something with data.val1, data.val2 and data.val3
});

DOM

Element.nodeName must always be used in favor of Element.tagName.

Element.nodeType must be used to determine the classification of a node (not Element.nodeName).

Iterating over Node Lists.

Node lists are often implemented as node iterators with a filter. This means that getting a property like length is O(n), and iterating over the list by re-checking the length will be O(n^2).

// not this good
var paragraphs = document.getElementsByTagName('p'),
    index;

for ( index = 0; index < paragraphs.length; index++ ) {
    doSomething(paragraphs[index]);
}

This works well for all collections and arrays as long as the array does not contain things that are treated as boolean false.

// good
var paragraphs = document.getElementsByTagName('p'),
    index;

for ( index = 0, paragraph; paragraph = paragraphs[index]; index++ ) {
    doSomething(paragraph);
}

// also good
var paragraphs = document.getElementsByTagName('p'),
    index, length;

for ( index = 0, length = paragraphs.length; index < length; index++ ) {
    doSomething(paragraphs[index]);
}

In cases where you are iterating over the childNodes you can also use the firstChild and nextSibling properties.

var parentNode = document.getElementById('foo'),
    child;

for ( child = parentNode.firstChild; child; child = child.nextSibling ) {
    doSomething(child);
}

Modules

Use CommonJS modules. Browserify, Webpack or similar are advised to bundle modules for web browsers.

eval() is only for code loaders and in general should be avoided.

It makes for confusing semantics and is dangerous to use if the string being eval()'d contains user input. There's usually a better, clearer, and safer way to write your code, so its use is generally not permitted.

Linting

Use ESLint to detect errors and potential problems.

The options for JSHint are stored in the .eslintrc.json example file.

Commits

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

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.

This preference comes from Git itself.

// bad
added feature X
adding feature X

// good
add feature X
fix problem Y

Provide a brief description of the change in the first line. If necessary insert a single blank line after the first line and provide a detailed description of the change in the following lines, breaking paragraphs where needed. Put the 'Change-id', 'Closes-Bug #NNNNN' and similar lines at the very end. More info.

switch libvirt get_cpu_info method over to use config APIs

The get_cpu_info method in the libvirt driver currently uses
XPath queries to extract information from the capabilities
XML document. Switch this over to use the new config class
LibvirtConfigCaps. Also provide a test case to validate
the data being returned.

redmine: #1003373
implements: blueprint libvirt-xml-cpu-model
change-id: I4946a16d27f712ae2adf8441ce78e6c0bb0bb657

All text files line endings are LF.

on Linux and OS X

# for a project
git config core.eol lf
git config core.autocrlf input

# or system-wide
git config --global core.eol lf
git config --global core.autocrlf input

on Windows

# for a project
git config core.eol lf
git config core.autocrlf true

# or system-wide
git config --global core.eol lf
git config --global core.autocrlf true

Name		Name	Last commit message	Last commit date
Latest commit History 89 Commits
.editorconfig		.editorconfig
.eslintrc.json		.eslintrc.json
.gitignore		.gitignore
license.md		license.md
readme.md		readme.md

License

DarkPark/jscs

Folders and files

Latest commit

History

Repository files navigation