I feel like if you just remove the spaces around the parens themselves, it's the most clear: ((a + b) / ((c - d) / e))
Nowhere I have worked would pass a code review for what you have proposed.
I feel like if you just remove the spaces around the parens themselves, it's the most clear: ((a + b) / ((c - d) / e))
Nowhere I have worked would pass a code review for what you have proposed.
Another example: do you write { foo: bar, baz: bat, bing: bang } or:
{
foo: bar,
baz: bat,
bing: bang
}
If you use the latter method, why wouldn't you write your expressions the same way? Obviously not the ultra simple ones like a + b, but the longer ones.Incidentally, I used to write code with no spaces between parens, which is what you suggested: ((a + b) / ((c - d) / e)), but eventually found it much easier to always put spaces around parens: ( ( a + b ) / ( ( c - d ) / e ) ). I would say this is similar to the indent-with-spaces-vs-tabs argument, which will rage forever.
To answer your earlier question about object definitions, in cases where the objects are small, I do think more concise (single line) notation can be more readable. An example, though not a great one because it's data more than it's code:
items: [
{ type: "a", quantity: "12", price: 123.45 },
{ type: "b", quantity: "7", price: 456.78 },
{ type: "c", quantity: "3", price: 9.00 },
]
If the number of properties exceeds say 3, or the names of them are complex, I would lean toward the longer form.