Object curlies: File/project–wide or standard?

[mightyiam]

So, we got #21 and that's great.

It got us instance–wide consistency.

Now, what about file–wide consistency, as was mentioned here?

And, now that I'm thinking about it, why not project–wide consistency?

And thinking further, why not choose a style as standard?

Either no spaces ({a, b}) or a single space ({ a, b }).

[timdp]

Personally, I've been struggling with the choice between {foo, bar} and { foo, bar } for a while. I think the former makes more sense because I also write [foo, bar], but it feels like I'm seeing the latter more often. Ultimately, I'm fine with either, but I'm basically expecting Standard to decide for me. Just my two cents.

[cayuu]

Agreed. I've seen a lot of inconsistency in a multi-person Standard project with different bikeshed preferences ensuring both styles {a} and { a } are being utilised in different files. When team {a} players land on { a } files (and vice versa), I'm seeing commits that do nothing other than change the spacing. 😜

We've rolled a custom rule to prevent this. But like, so non-Standard.

Also don't care which style prevails, but picking one seems squarely in Standard's decision space.

[PrototypeAlex]

I thought I was alone on struggling to pick a side on this, but it seems the lack of clear choice is quite common.

Is the hard part what @timdp pointed out?
The fact that choosing a rule for object culries might force a rule for arrays? or can both live in harmony being different from one another?

const array = [one, two];
const object = { one, two }; 

const array = [one, two];
const object = {one, two}; 

const array = [ one, two ];
const object = { one, two }; 

[dcousens]

@feross, it might be time to "just pick something" for the next version IMHO. I'd be happy with either:

const array = [one, two];
const object = { one, two }; 

const array = [one, two];
const object = {one, two}; 

But, I don't mind as long as it is enforced.

[jokeyrhyme]

Apparently the --fix option works: http://eslint.org/docs/rules/object-curly-spacing

Surely the fact that compliance can be automated like this makes this a less controversial change? Why would you bring 1 or 2 files into compliance rather than the whole project, when doing the whole project is this simple?

[feross]

@dcousens I'm fine with going with your latter example, since that's more consistent. I usually add spaces around my objects, but consistency is more important. If --fix can handle it, then it's probably fine to just ship this.

[timdp]

Looks like I'm going to be fixing a lot of scripts soon, but all the better! 👍

[dcousens]

@feross my only aversion to the latter is

let map = {a: 1}

instead of

let map = { a: 1 }

I think the spacing keeps up a form of spacial difference, where the tightly packed array allows you immediately recognize it. Obviously subjective.

Removing padding spaces from object definitions might actually lead to mistakes since it looks closer to an array.
Maybe.

[feross]

You raise a good point. This is definitely very subjective. 😅

Btw, it would be:

let map = {a: 1}

Not:

let map = {a:1}

[dcousens]

I wonder if either is "easier" to search for?
I have fallen in love with function myfunc () {} for that reason alone.

[cayuu]

{ a: 1 } is more readable, {a: 1} is more consistent (with other single line enclosure syntax e.g.: [x, ..], (x, ..)). This is pure convention, so either choice is "valid". But if consistency is the yardstick, the tight wrap has an edge.