Javascript: Why do you use object-curly-spacing

[constantyn]

Hi airbnb team,
Can give us your thinking behind applying the object-curly-spacing rule?
I can think of only one: it distinguishes the arrays from the objects. Or do you have another reason?

[ljharb]

Are you asking why there's a rule to enforce it, or why we chose the config we did?

It's enforced because everything that can be enforced should be; because consistency is paramount; and because nobody should have to argue on a PR about curly brace spacing.

[jacksbox]

I would be also interested in this question:
In similar situations, e.g. the function definition foo(b, a = 2), or array definition [0, 1, 2] it is the other way around. I would think that if its better for readability in one place, then in the other too... or is there another reason?

[ljharb]

In both those cases, they're lists of items; the comma is sufficient to separate them.

In the case of objects, they're key/value pairs; the spacing helps avoid confusion here.

[ackvf]

What about imports or destructuring assignment? They are also syntacticaly lists and not key/value pairs. How would you justify this [5.2], [5.3]?

function returnArray() {
  ...
  return [top, right, bottom, left];
}

function returnObject() {
  ...
  return { top, right, bottom, left };
}

const [top, right] = returnArray();
const { top, right } = returnObject();

[ljharb]

@ackvf that's a very good point on imports; but there's also the issue of consistency between curly brace forms. Destructuring assignment a) is still a shorthand for key/value pairs, and b) can have both when renaming, like const { top: renamedTop, right } = returnObject();; additionally, named imports can have renaming with as - the possibility of the extra info justifies the extra spacing alone imo, alongside the desire for consistency with normal object literals.

[ackvf]

Okay, it depends on how we look at it and you are right that after all we use arrays and objects to destructure other arrays and objects. So if we have let arr = [1, 2, 3], we use another _array_ that matches the signature to extract the values from it, same with objects let obj = { a: 1, b: 2, c: 3 }.

let [a, b, c] = [1, 2, 3]
let { a, b, c } = { a: 1, b: 2, c: 3 }

As you can see the resulting code looks ugly and at first glance it seems as an inconsitent styling.

My personal prefered reasoning is to use spacing for blocks and _not_ use spacing for primitives and structures that resemble them - e.g. use object notation for destructuring.

For example, I would go the other way round (in jsx):

<MyButton values={ [1, 2, 3] } object={ {a:1, b:2, c:3} } /> _array/object within blocks_

But the question is, do import/exports use _object notation_ or something that rather resembles _blocks_?

[ljharb]

It's using array and object syntax, but it's not arrays and objects - specifically, iterable destructuring (not array destructuring, there's no such thing) uses the iterable protocol, which is different.

I don't agree that it's ugly or that it's inconsistent.

named imports/exports are also not objects, nor destructuring - it simply overloads object literal syntax. It's far more like an object than like a block (it's not a block in any way), but it's not an object either.

[dharcourt]

I also find spaces in curly braces neither ugly nor inconsistent with the array rules.

However, it does seem inconsistent with historical JavaScript usage and references. For example neither the JSON reference example page nor Mozilla's developer web site (like the Object Initializer and Destructuring Assignment pages) have spaces inside their curly brace expressions. Similarly, most older style guide, like Google's, recommends against spaces.

Of course, there is no requirement to have any aspect of the Airbnb style guide match specifications, references, and older style guides, but it would make it easier for developers previously working in another style to adopt the Airbnb style, for non-Airbnb developers to read Airbnb-styled code, and for all developers to go between Airbnb formatted code and other code, especially the code examples in reference materials.

Do the benefits of a slightly better separation of key-value pairs in curly braces offset the cost of ditching the preexisting consensus for this small aspect of JavaScript style?

[ljharb]

It's also the case that in the previous decade, declaring all variables at the top of the function with a single var keyword was common; both are no longer the case. The benefits of this separation absolutely offsets the minor cost of "what's conventional" evolving over time.

This seems pretty thoroughly answered; closing.

[manfreed]

I wanted to create a separate issue for my comment, I hope it's OK to revive this thread to add one more question, which would be too little for a separate issue?

Wouldn't using https://eslint.org/docs/rules/array-bracket-spacing be a good compromise and a solution for the code above? I'm kinda selfish here, but I see the benefits. On our projects we actually are using this with airbnb rules as a base, we'd however prefer to stay as close as possible. :)

[ljharb]

@manfreed i think https://github.com/airbnb/javascript/issues/1407#issuecomment-386058657 remains the case.