felixge / node-style-guide Goto Github PK
View Code? Open in Web Editor NEWA guide for styling your node.js / JavaScript code. Fork & adjust to your taste.
A guide for styling your node.js / JavaScript code. Fork & adjust to your taste.
Thanks for the great guide.
I wonder what about File naming conventions for js files, files can be modules or class
For example how class file for CustomerInvoice class be named?
Camel case or snake case?
Thanks.
Hey, what about .jscsrc config to add here?
There is an additional comma after the last key/value pair on the 'Right' example.
var b = {
good: 'code',
'is generally': 'pretty',
};
Hey, would you be able to push this project to npm? It would be super useful for extending ESLint config from.
Thanks!
May your guide ever be holy, however:
Using ESLint it tells me to use double-quotes with strings....what the hell.
18:0 error Strings must use doublequote quotes
Please advise.
I'm not sure if this should fall under the scope of the style guide, but should requirements be verbose?
E.g.
var sample = require('./routes');
vs
var sample = require('./routes/index.js');
Or
var other = require('./routes/other');
vs
var other = require('./routes/other.js');
I personally always include them, to avoid any accidental conflicts that might be cause by editor autosaves, or something wonky, yet Express uses the former rather than the latter.
This is just one thing I was pondering, since the latter seems like a better practice. However, I'm not sure it actually warrants inclusion in the style guide.
Shouldn't there be a section for comments? Like pointing out what to use and when. Examples:
# With a hash sign
// With slashed
/**
* Multiline
*/
/*
* Multiline with one asterisk on first line
*/
// Multiline through
// slashes
# Multiline through
# hashes
// Doc right over the code
var key = 'value';
// Doc with a spacer between comment and code
var key = 'value';
I think that this part should be updated to reflect the current situation:
Node.js / V8 actually supports mozilla's const extension, but unfortunately that cannot be applied to class members, nor is it part of any ECMA standard.
I agree with spaces instead of tabs and never mixing them.
But here is why "2" spaces should not be on the list:
Since this is a list for driving a convention, I believe this should be considered.
Cheers.
How about function declarations? It drives me nuts when I see
var packAssets;
packAssets = function(...) {
return packed;
}
I don't understand why people do this. If you call it before the declaration packAssets will be undefined.
Use:
printHTML
or printHtml
(for variables)
DB
or Db
(for class)
MyXML
or MyXML
(for class)
I'm a big fan of docblocks, and it's the only place I will use a multi-line comment:
/**
* Function description here.
*
* @param {string} test Some argument.
*/
function doSomething(test) {}
It works great with IDEs—mine will give me a warning if the arguments don't match up to the comment, and then when I use the function will validate the input to make sure it's the correct type, which also helps keep the docs up to date.
There are tools such as JSDoc which will parse these to generate documentation for you.
This syntax is currently disallowed in node-style-guide, and I find it pretty useful. Would you accept a PR that adds something like the following?
The only case a multi-line comment is allowed is as a docblock immediately before a function:
// The code block from above
Hi,
Its a feature request . Can you please update the style guide with ES6 ?
Hi~~, guide is great! And Can I translate it to Chinese ?
The whole point of the ternary operator ( var foo = condition ? val1 : val2) is to be succinct. In every language where it is used it is expressed in one line, otherwise the if/then/else makes more sense. This has been the case for at least 20 years.
What is the justification for recommending that ? and : be on separate lines?
2 space indentation doesn't actually looks good when the name of variables and method/functions gets longer, since it won't align the body of, say if statement, to the if condition which also happens to loops etc . Check the following
2 space:
if (checkPointer !== undefined && checkPointer !== null) {
checkPointer.checkpoint(blah_blah, function (err) {
if (!err) {
log.info('blah_blah.................................');
}
checkpointComplete(err);
});
} else {
log.info("blah_blah..............................");
checkpointComplete();
}
4 space:
if (checkPointer !== undefined && checkPointer !== null) {
checkPointer.checkpoint(blah_blah, function (err) {
if (!err) {
log.info('blah_blah..........................');
}
checkpointComplete(err);
});
} else {
log.info("blah_blah....................................");
checkpointComplete();
}
ESLint is a great tool.
Why not adding .eslintrc
such a .jshintrc
?
Been using this excellent guide's .eslintrc for a while now and started getting this error after updating ESLint today: "Rule 'space-after-keywords' was removed and replaced by 'keyword-spacing'".
Turns out space-after-keywords was removed in ESLint v2.0.
Strings should use single qoute...the jshintrc has double.
"camelcase": true,
^ Strings must use singlequote.
10 | "curly": true,
^ Strings must use singlequote.
11 | "eqeqeq": true,
^ Strings must use singlequote.
12 | "freeze": true,
^ Strings must use singlequote.
13 | "indent": 2,
^ Strings must use singlequote.
14 | "newcap": true,
^ Strings must use singlequote.
15 | "quotmark": "single",
^ Strings must use singlequote.
15 | "quotmark": "single",
^ Strings must use singlequote.
16 | "maxdepth": 3,
^ Strings must use singlequote.
17 | "maxstatements": 15,
^ Strings must use singlequote.
18 | "maxlen": 80,
^ Strings must use singlequote.
19 | "eqnull": true,
^ Strings must use singlequote.
20 | "funcscope": true,
^ Strings must use singlequote.
21 | "node": true
I have no issue with the advice of using === by default, but it really is silly to tell people to write
if (result === undefined || result===null) {
when you can do
if (result==null) {
In most cases you want to catch both.
I agree that multi-line ternary operators make sense. However, the following is (as far as I know) bad, due to ASI:
var foo = (a === b)
? 1
: 2;
JShint will throw an error on this code, saying “Bad line breaking before '?'”.
If you insist on using multi-line ternary operators, you might prefer the following style:
var foo = (a === b) ?
1 :
2;
I agree that it is less readable, because the question mark and the colon are more obvious at the beginning of the line. But I wouldn’t want to mess with ASI and depend on implicit fixes of the JS engine, either.
There were topics that wasn't at the TOC, I've made a PR to add them and fix it. @felixge, tks for the excellent guide.
If its relevant, I'd love to see a section on the preferred naming of files within in a project. For example, should it be:
buffer-utils.js
buffer_utils.js,
bufferUtils.js
?
https://github.com/felixge/node-style-guide#declare-one-variable-per-var-statement
You say to ignore Crockford and give a link (http://javascript.crockford.com/code.html), however, from what I can tell you are of the same opinion.
It is preferred that each variable be given its own line and comment. They should be listed in alphabetical order.
var currentEntry; // currently selected table entry var level; // indentation level var size; // size of table
How about a comment to use ES6 shims to gain more methods on builtin objects?
Hi, I was wondering about the 80 chars per line guideline and I had some arguments against this guideline and I wanted to know what you think of them:
(I know this is just your guideline but I was wondering if I'm missing something, more arguments pro this guideline)
(as a reminder, the readme currently says:)
Limit your lines to 80 characters. Yes, screens have gotten much bigger over the last few years, but your brain has not. Use the additional room for split screen, your editor supports that, right?
What if we allowed more than 80 characters? Would it be so bad? People who prefer longer lines can use the code like normal, people who want lines that are max 80 chars long can use soft wrap, because most editors support this too!
=> If you would limit your lines to 80 chars, then people who like everything on one line can't have it so you force everyone to use 80 char long lines tops. While in the other scenario, people can see the code in the way they prefer.
Great guide, thank you!
I was sad to see Object.freeze at the bottom, included in the 'Crazy shit' group. I've been using it in some of my projects lately, but only by using the constant naming convention, like enums. There are also some speed optimizations appearing when using Object.freeze. Any further thoughts on this? Would it make sense to take it out of the 'Crazy shit' group, when used with a naming convention?
A little more info with a small example:
http://stackoverflow.com/a/31906266/2280394
I tried using the .eslintrc file w/ [email protected] and got the following error:
Rule
space-in-brackets
was removed and replaced by:object-curly-spacing
,array-bracket-spacing
,computed-property-spacing
.
I prefer to move logic constructions in separated lines:
if (a) {
// ...
}
else if (a != b) {
// ...
}
else {
// ...
}
This makes code more git friendly (like trailing commas). And also it makes it simple to comment else if
and else
sections. Each block is prepended with it's own condition.
Use closures, but don't nest them.
https://github.com/felixge/node-style-guide#no-nested-closures
This is a little funny considering the whole point of closures is to nest them so they close over variables in their parent scope.
The examples provided are just.. regular functions.
I love everything in your guide, other than the getter and setter portion.
I've found getters and setters to be extremely valuable and performant.
Check out this code to see what I mean:
https://github.com/jsdevel/webdriver-sync/blob/master/src/imports.js
Those imports causes a massive initial load time. Getters facilitate lazy loading in a very DRY manner.
Should use the combination of PascalCase for the former and camelCase for the latter to be more succinct.
"always return a function's value as early as possible"
I think you should put some caveats on this. Returns (and breaks and other break out statements) buried inside blocks of code are easily missed and are a very significant source of bugs on later modifications to the code (I speak with many years of experience).
For me returns should either be in the first few lines of the function (where some simple ifs deal with trivial cases) or in the last few lines of a function.
If one has to put a return in the middle of a longer function then I would make it stand out with a comment so it is not easily overlooked.
return; // ****************** RETURN *********************
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.