5 ms·
> One thing that working on the project helped demonstrate for me is that adding parens around _every_ subexpression is _way_ too noisy. But for me, I prefer dr
by kmoser 3y ago
> One thing that working on the project helped demonstrate for me is that adding parens around _every_ subexpression is _way_ too noisy. But for me, I prefer drawing that line on the noisier side.
I prefer the noisier side as well. When adding parens to indicate/force precedence, I will sometimes split my expressions into multiple lines, with indentation, as an aid to legibility, e.g. instead of ( ( a + b ) / ( ( c - d ) / e ) ) I might write:
(
( a + b )
/
(
( c - d )
/
e
)
)
I've found this not only quite legible, but also fairly easy to edit because you can easily match parens visually.
- kawhah 3y agoThanks, I hate it.
- FlyingAvatar 3y agoI 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 agoIf 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 agoThis. 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 agoAhh, 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 agoI'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.
- rmetzler 3y agoI would rather argue to add temp variables and name parts of the expression, so you can actually understand and communicate what this does.
- deleted 3y ago[deleted]
- benj111 3y agoTell me you're a lisp programmer without telling me you're a lisp programmer. The thing for me is my text editor visually matches the braces, so the second option makes that harder.