3 ms·

I appreciate the attempt, but don't the explicit parens make it pretty clear? I feel like if you just remove the spaces around the parens themselves, it's the

I appreciate the attempt, but don't the explicit parens make it pretty clear? 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.

innocenat 3y ago
If it isn't just a b c d e but longer variable name or function call, then I imagine it wouldn't be as clear.
- kmoser 3y ago
  This. An extreme example, where I think my solution works best, is SQL statements that are hundreds of lines long. No sane developer would put that all on one line.
  - FlyingAvatar 3y ago
    Ahh, I think your example would have communicated the benefit of what you were sharing more clearly with longer variable names. For single word variables, though, it feels needlessly verbose. 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.
kmoser 3y ago
I'm curious, what is it about my multi-line expression is unclear? I find it easier to match parens when they line up vertically (similar to aligning braces in C functions) than when they're all on one line. True, most IDEs will happily show you a matching paren when you hover over one, but that still doesn't help you understand how a long, one-line expression really breaks down. 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.

innocenat 3y ago

If it isn't just a b c d e but longer variable name or function call, then I imagine it wouldn't be as clear.

kmoser 3y ago
This. An extreme example, where I think my solution works best, is SQL statements that are hundreds of lines long. No sane developer would put that all on one line.
- FlyingAvatar 3y ago
  Ahh, I think your example would have communicated the benefit of what you were sharing more clearly with longer variable names. For single word variables, though, it feels needlessly verbose. 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.

kmoser 3y ago

I'm curious, what is it about my multi-line expression is unclear? I find it easier to match parens when they line up vertically (similar to aligning braces in C functions) than when they're all on one line. True, most IDEs will happily show you a matching paren when you hover over one, but that still doesn't help you understand how a long, one-line expression really breaks down. 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.