Rule for enforcing JSON-style hash keys

[mcandre]

In JSON, hash keys must be strings. Could there be a rule for using strings for all hash keys in regular .js code?

[maxkueng]

👍

[xjamundx]

In JSON, object literals need to have double-quoted keys. Is that what you actually want to check for? Are single quotes fine as well? Seems a bit unclear to me what you're trying to achieve or why!

[rwaldron]

-1

JS stores properties as strings internally, but why would you want to clutter the program code with "" or '' everywhere?

[maxkueng]

It would be cool to be able to enforce

var obj = {
    'x' : 300,
    'y' : 200
};

instead of

var obj = {
    x : 300,
    y : 200
};

Consider this function:

function objectify (x, y) {
    return {
        x : x,
        y : y
    };
}

For readability, it is much clearer to explicitly use strings for the hash keys even though they are already interpreted as strings by JavaScript. Because the hash key "x" could be confused with the value of the variable x.
It has nothing to do with actually being JSON-compatible.

[nschonni]

The only case I can think of where the quoting is required in JS is for keys that have special characters

var foo = {
  "awesome-value" : 1
};

The unquoted version would already be caught as malformed JS though.

[neonstalwart]

it makes no sense to enforce those quotes where they aren't needed. i would prefer to have developers demonstrate that they understand the language by only quoting when necessary. i don't think it would be cool to be able to enforce that style at all when there is no benefit to it.

[rwaldron]

@maxkueng I don't see anything cool about either of those examples. They look like more typing that results in more clutter.

Besides, this function:

function objectify (x, y) {
    return {
        x : x,
        y : y
    };
}

...is soon to be obsolete.

In ES6, property definition shorthands will allow:

function objectify(x, y) {
    return { x, y };
}

var o = objectify(1, 2);

console.log(o);

/*
{
  x: 1, 
  y: 2
}
*/

[mcandre]

I believe the best solution would be to have a rule, hashkeystyle or such, that behaves like quotmark, accepting either true to detect different syntaxes in the same file, or one of several possible styles:

• json for quoted keys
• es5 for unquoted keys
• es6 for comma-separated values.

... and if we're really going for it, we could have an es6 rule that sets hashkeystyle to es6 by default.

[tomByrer]

+1 mcandre's suggestion for flagging.
Personally, I do not think any of our individual opinions should really matter; it should be up to a coding team's decision to go with or sans. It would be great if a tool could help enforce either decision. Tools to translate would be trivial & will help quench arguments (like for tab vs space indenting; just have your editor translate).

While I can not find any style guide that points out that object keys must be quoted, NPM gives an example in theirs that is pro-quotes.

I can argue both sides, but I'll drop it for now.

[rwaldron]

@tomByrer are you seriously suggesting that code such as that should be taken seriously?

I'm going to wash the blood from my eyeballs now. Thanks.

[tomByrer]

@rwldrn Thank you for your feedback. I'm sorry it caused such a shock to you, I pray you did not require hospitalization.

[valueof]

JSHint is moving away from styling options. No new styling feature requests will be accepted. Sorry.