3 ms·

If i saw that in a colleague's code, i'd be angry at them as that's not legible.

scotty79 4y ago
It's no less legible than original code and at least expresses the intent of what's being processed, what are the processing steps and what are processing parameters. a(b(),c(),d(e(),f(g()))) is just function call soup.
- yamtaddle 4y ago
  At least I can instantly tell which call is ultimately returning something, in that version.
  - scotty79 4y ago
    There's nothing preventing you from not using the pipe for last call or even introducing that rule in your team if you can convince your colleagues it's a good idea or even automate it with the use of a linter. If it's really good rule you can advocate for it at this stage. It might be prudent to use |> % only inside function call parameter or possibly as right hand of an assignment instead of everywhere where parser expects an expression. a(b(),c(), g() |> f(%) |> d(e(), %)) Although I'll be honest, I don't like it. Other parameters of a() call for me occlude the flow and the intent. We could make it a bit better with newlines. a(b(),c(), g() |> f(%) |> d(e(), %)) ) But if a() takes more parameters after the main one then we have the same problem as usual where parts of the same call can end up far away from one another. a(b(),c(), g() |> f(%) |> d(e(), %)) x(), y(), z()) For me g() |> f(%) |> d(e(), %)) |> a(b(), c(), %, x(), y(), z()); is still better and I wouldn't want it to be prevented by language syntax.
    - yamtaddle 4y ago
      That's almost worse. I think I'd have to break out pen and paper to figure out which of those things end up returning arguments to function "a".
      - scotty79 4y ago
        I agree that such restriction would make it worse.
- _boffin_ 4y ago
  And I’d be angry if I saw that too. Break out the soup into variables and have it all be In a clean layout
  - coffeebeqn 4y ago
    Use a functional language if you want to chain 10 functions together! I would definitely tell them in the PR to stop being clever and rewrite it

It's no less legible than original code and at least expresses the intent of what's being processed, what are the processing steps and what are processing parameters. a(b(),c(),d(e(),f(g()))) is just function call soup.

yamtaddle 4y ago
At least I can instantly tell which call is ultimately returning something, in that version.
- scotty79 4y ago
  There's nothing preventing you from not using the pipe for last call or even introducing that rule in your team if you can convince your colleagues it's a good idea or even automate it with the use of a linter. If it's really good rule you can advocate for it at this stage. It might be prudent to use |> % only inside function call parameter or possibly as right hand of an assignment instead of everywhere where parser expects an expression. a(b(),c(), g() |> f(%) |> d(e(), %)) Although I'll be honest, I don't like it. Other parameters of a() call for me occlude the flow and the intent. We could make it a bit better with newlines. a(b(),c(), g() |> f(%) |> d(e(), %)) ) But if a() takes more parameters after the main one then we have the same problem as usual where parts of the same call can end up far away from one another. a(b(),c(), g() |> f(%) |> d(e(), %)) x(), y(), z()) For me g() |> f(%) |> d(e(), %)) |> a(b(), c(), %, x(), y(), z()); is still better and I wouldn't want it to be prevented by language syntax.
  - yamtaddle 4y ago
    That's almost worse. I think I'd have to break out pen and paper to figure out which of those things end up returning arguments to function "a".
    - scotty79 4y ago
      I agree that such restriction would make it worse.
_boffin_ 4y ago
And I’d be angry if I saw that too. Break out the soup into variables and have it all be In a clean layout
- coffeebeqn 4y ago
  Use a functional language if you want to chain 10 functions together! I would definitely tell them in the PR to stop being clever and rewrite it