felixge / node-style-guide Goto Github PK

Should use the combination of PascalCase for the former and camelCase for the latter to be more succinct.

Hey, what about .jscsrc config to add here?

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

.i have this line

app.listen(PORT, () => { console.log(`app running on http://localhost:${PORT}`)});

basically i want it to be a single line while i keep the rule for other normal function.
here is. how it errors in vs code

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.

ESLint is a great tool.
Why not adding .eslintrc such a .jshintrc?

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
?

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.

Hey, would you be able to push this project to npm? It would be super useful for extending ESLint config from.

Thanks!

https://github.com/felixge/node-style-guide#name-your-closures

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.

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

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.

How about a comment to use ES6 shims to gain more methods on builtin objects?

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

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.

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.

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.

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.

Use:
printHTML or printHtml (for variables)
DB or Db (for class)
MyXML or MyXML (for class)

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.

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.

"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 *********************

There is an additional comma after the last key/value pair on the 'Right' example.

var b = {
  good: 'code',
  'is generally': 'pretty',
};

Check it out.

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();
            }

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 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 with spaces instead of tabs and never mixing them.
But here is why "2" spaces should not be on the list:

• The number of spaces used for indention might be an accessibility concern. For some people, 2 space indention might make it really harder to read the code.
• With some fonts, it might get worst.
• This can't be an issue for saving bytes; since you should minify your code for client-side anyway; and not a real concern in Node/on server-side.
• This is JS. But Python, as a language highly depending on indention recommends 4 spaces. There is a reason.

Since this is a list for driving a convention, I believe this should be considered.
Cheers.

Hi~~, guide is great! And Can I translate it to Chinese ?

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

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?

https://github.com/felixge/node-style-guide#declare-one-variable-per-var-statement

Thanks !

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.

Hi,
Its a feature request . Can you please update the style guide with ES6 ?

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.

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.