JavaScript does not have an authoritative coding style guide, but instead it is some popular coding styles:
The code copy is as follows:
Google's JavaScript Style Guide (hereinafter referred to as Google)
http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml
NPM encoding style (hereinafter referred to as NPM)
https://npmjs.org/doc/coding-style.html
Felix's Node.js style guide (hereinafter referred to as Node.js)
http://nodeguide.com/style.html
Idiomatic JavaScript (hereinafter referred to as Idiomatic)
https://github.com/rwldrn/iiomatic.js/
jQuery JavaScript Style Guide (hereinafter referred to as jQuery)
http://contribute.jquery.org/style-guide/js/
Douglas Crockford's JavaScript Style Guide (hereinafter referred to as Crockford), Douglas Crockford is one of the most well-known technical authorities in the field of web development and a member of the ECMA JavaScript 2.0 Standardization Committee
http://javascript.crockford.com/code.html
Of course, there are also some default settings choices in the JavaScript syntax checkers JSLint and JSHint. The question is, what is the ultimate JavaScript coding style that most developers can follow? Let's find some consensus styles from these 6 style guides below.
1. Code style comparison
1.1 Indentation
Two spaces, no longer indentation, no Tab indentation: Google, NPM, Node.js, Idiomatic
Tab Indent: jQuery
4 spaces: Crockford
1.2 Spaces between parameters and expressions
Use compact styles: Google, NPM, Node.js
Copy the code as follows: project.MyClass = function(arg1, arg2) {
Too much use of spaces: Idiomatic, jQuery
Copy the code as follows: for ( i = 0; i < length; i++ ) {
No comments: Crockford
In most guides, developers are reminded not to have any spaces at the end of a statement.
1.3 Code line length
Up to 80 characters: Google, NPM, Node.js, Crockford (When in a code block, other indents except 2 spaces allow the function parameters to be aligned with the position of the first function parameter. Another option is to use 4 spaces to indent when wrapping the line instead of 2.)
No comments: jQuery, Idiomatic
1.4 Semi-colon
Always use semicolons, not relying on implicit inserts: Google, Node.js, Crockford
Do not use expect:NPM in some cases
No comments: jQuery, Idiomatic
1.5 Comments
Follow JSDoc conventions: Google, Idiomatic
No comments: NPM, Node.js, jQuery, Crockford
1.6 Quotes
Recommended single quotes: Google, Node.js
Double quotes: jQuery
No comments: NPM, Idiomatic, Crockford
1.7 Variable declaration
Declare one at a time without using commas: Node.js
The code copy is as follows:
var foo = ”;
var bar = ”;
Declare multiple at once, use commas to separate at the end of the line: Idiomatic, jQuery
The code copy is as follows:
var foo = "",
bar = "",
quux;
Use comma at the beginning of the line: NPM
No comments: Google, Crockford
1.8 Braces
Use the opening braces on the same line: Google, NPM, Node.js, Idiomatic, jQuery, Crockford
Copy the code as follows: function thisIsBlock(){
The NPM guide states that only use braces when the code block needs to include the next line, otherwise it will not be used.
1.9 Global variables
Don't use global variables: Google, Crockford (Google says global variable naming conflicts are difficult to debug, and may have some tricky problems when two projects are being integrated. To facilitate sharing of common JavaScript code, conventions need to be made to avoid conflicts. Crockford believes that implicit global variables should not be used.)
No comments: Idiomatic, jQuery, NPM, Node.js
2 Naming Style
2.1 Variable Naming
The first word at the beginning is lowercase, and the first letter of all words afterwards is uppercase: Google, NPM, Node.js, Idiomatic
The code copy is as follows:
var foo = "";
var fooName = "";
2.2 Constant Naming
Use capital letters: Google, NPM, Node.js
The code copy is as follows: var CONS = 'VALUE';
No comments: jQuery, Idiomatic, Crockford
2.3 Function Naming
The first word at the beginning is lowercase, and the first letter of all words afterwards is uppercase (camel): Google, NPM, Idiomatic, Node.js (it is recommended to use long, descriptive function names)
The code copy is as follows:
function veryLongOperationName
function short()..
Function naming in keyword form:
The code copy is as follows:
function isReady()
function setName()
function getName()
No comments: jQuery, Crockford
2.4 Array Naming
Use plural form: Idiomatic
The code copy is as follows: var documents = [];
No comments: Google, jQuery, NPM, Node.js, Crockford
2.5 Object and class naming
Use the following forms: Google, NPM, Node.js
The code copy is as follows:
var ThisIsObject = new Date;
No comments: jQuery, Idiomatic, Crockford
2.6 Other naming
Use all-lower-hyphen-css-case for long file names and configuration keys: NPM
3. Configure the .jshintrc file according to the above style
JSHint (http://www.jshint.com/) is a JavaScript syntax and style checking tool that you can use to remind code style related issues. It can be well integrated into many commonly used editors and is a great tool for unifying team coding styles.
You can view available options through the JSHint documentation: http://www.jshint.com/docs/#options
The following is to create a .jshintrc file based on the first style under each of the above categories. You can put it in the root directory of the project, and the JSHint-avare code editor will unify all code styles in the project according to it.
The code copy is as follows:
{
"camelcase" : true,
"indent": 2,
"undef": true,
"quotmark": single,
"maxlen": 80,
"trailing": true,
"curly": true
}
Additionally, you should add the following header to your JavaScript file:
The code copy is as follows:
/* jshint browser:true, jquery:true */
In the Node.js file you should add:
The code copy is as follows:
/*jshint node:true */
You can also add the following statement in various JavaScript files:
The code copy is as follows:
'use strict';
This will affect JSHint and your JavaScript engine and may not be so compatible, but JavaScript will run faster.
4. Automatically execute JSHint before committing Git
If you want to make sure that all JS code is consistent with the style defined in .jshintrc, you can add the following to your .git/hooks/pre-commit file, and the style check will be automatically performed when you try to submit any newly modified files to the project.
The code copy is as follows:
#!/bin/bash
# Pre-commit Git hook to run JSHint on JavaScript files.
#
# If you absolutely must commit without testing,
# use: git commit --no-verify
filenames=($(git diff --cached --name-only HEAD))
which jshint &> /dev/null
if [ $? -ne 0 ];
Then
echo "error: jshint not found"
echo "install with: sudo npm install -g jshint"
exit 1
fi
for i in "${filenames[@]}"
do
if [[ $i =~ /.js$ ]];
Then
echo jshint $i
jshint $i
if [ $? -ne 0 ];
Then
exit 1
fi
fi
done