-
Notifications
You must be signed in to change notification settings - Fork 65
JavaScript Code Etiquette
yarn run prettier
You can can also run a git hook (see Husky, below)
Proof-of-Concept branch on eslint-prettier
- JavaScript Linter
- Warns you about potential bad code such as
- unused variables (maybe you created a variable and forgot to use it)
- used variable that hasn't been defined yet
- and sooo much more ...
- can automatically fix formatting and coding style
- ESLint + Prettier is more powerful than ESLint alone
- can warn you
- don't have to worry whether your code meets the code etiquette (see below)
- Prettier formats it for you
- git hooks
- scripts that run when certain events happen
- eg: pre-commit runs before a commit is made
- pre-commit: if code doesn't meet Prettier standards, it won't let you commit
- More here
If there is a code snippet like this:
foo(reallyLongArg(), omgSoManyParameters(), IShouldRefactorThis(), isThereSeriouslyAnotherOne(), noWayYouGottaBeKiddingMe());
ESLint will: warn you that it's too wide
Prettier will: actually format it for you
foo(
reallyLongArg(),
omgSoManyParameters(),
IShouldRefactorThis(),
isThereSeriouslyAnotherOne(),
noWayYouGottaBeKiddingMe()
);
Read this to learn more https://github.com/prettier/prettier-eslint/issues/101
If blocks should be of the form
if (condition) {
...
} else {
....
}
(2019-02: update: ES6/ES2015+ modules are always in strict mode, don't have to explicitly define)
The use strict statement at the top of a function is absolutely necessary. The use-strict statement lies underneath the function declaration, and has a blank line following it. It tells the compiler not to be lenient with the JavaScript code, which can be the first line of defence against syntactically incorrect or buggy code.
- No implicit var declarations.
- ie: use var (or const or let) when declaring a variable
- No duplicate variable declarations or shadowing.
- Declare
var
iables at the top of the function, after the aforementioned use-strict's following blank line.
- Always use semicolons. The JavaScript engine has the ability to infer semicolons, but omitting them is frowned upon.
- Spacing in equations is necessary.
var x=2+2*65/2
<var x = 2 + 2 * 65 / 2
.
- Keep in mind that parenthesis might help future programmers read your equations. Let's take the above example, but add in some more bits.
var x = 2 + 2 * 65 / 2^3 + 65 / 3
is a bit of an eyeful (maybe not the best case, but it can get the point across). Try simplifying it for the reader like:var x = 2 + ((2 * 65) / 2^3) + (65 / 3)
.
- Put a double space in between function declarations.
- CONSTANTS_ARE_IN_UPPERCASE.
- The rest are in camelCase.
- Duplicated selectors can and often should be cached for efficiency.
var circleObject = $("#circle");
- camelCase.
- Imperative voice (Things such as
makeNode()
)
var x = 1 + 2 + 3 +
4;
is preferred over
var x = 1 + 2 + 3
+ 4;
Likewise,
if (i === "i" ||
i === "j") {
...
}
is preferred over
if (i === "i"
|| i === "j") {
...
}
-
'
is necessary.