Skip to content

Rule for enforcing JSON-style hash keys #1050

Closed
mcandre opened this Issue May 2, 2013 · 12 comments

8 participants

@mcandre
mcandre commented May 2, 2013

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

@maxkueng
maxkueng commented May 3, 2013

👍

@xjamundx
xjamundx commented May 3, 2013

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
JSHint member
rwaldron commented May 3, 2013

-1

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

@maxkueng
maxkueng commented May 3, 2013

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
nschonni commented May 3, 2013

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
JSHint member
rwaldron commented May 3, 2013

@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
mcandre commented May 5, 2013

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
JSHint member

@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 member
valueof commented Dec 28, 2013

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

@valueof valueof closed this Dec 28, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.