Comment by psychoslave
1 month ago
Turning a 100+ lines function of 5+ intertwined control flow mess into a single expression using a combination of method chaining of just a few lines is always a delighting experience to my mind.
1 month ago
Turning a 100+ lines function of 5+ intertwined control flow mess into a single expression using a combination of method chaining of just a few lines is always a delighting experience to my mind.
Until a coworker needs to debug a specific edge case that was too specific for the single expression, and it all has to be rewritten back to long form. Dense code is not always better and sometimes makes a code base incomprehensable.
I've experienced this watching a coworker debugging that sort of code, he had initially written it all as a long chained statements, then had to undo it all to allow him to debug. Once it was extracted it could be debugged and step through it, great!
Once he was done debugging it he put it all back to how it was originally...
The mind boggles.
Ahh, the fabled "write-only" code.
Looks like a limited debugger unable to let inspect what's happening in each chained function. Or is that something else?
I mean, it looks like the same level as adding explicit temporary variable because the debugger won't give provide values of the different part of an expression assigned to a third variable. That's a way to circumvent the tool limitation, just as you can add a tap or map in a middle of a chain if the debugger is too rudimentary to provide more conveniency.
Single use long functions are great for debuggability and following the code path.
Injection or whatever fancy term used for passing function pointers around is ofent write only.
If the function is long, accumulate variable along the way, and open intertwined control flow every three lines, no a single function is not at all a scalable way to expose a construction involving many transformations and sources and debugging will be as hard as the control follow depth times number of stacked variable so far as it's stepped through.
With method chaining at each step you have only the complexity of the current method inputs to deal with: that's a far better noise/signal ratio.
No, with chained methods it's just as easy to move step by step in each method, and even in bodies of anonymous functions that you might pass as parameter. At least with a decent contemporary IDE and debugger.
The reason code is terser is because it forces to streamline the process to a single output at a time, rather than an unrestricted number of variable control flow and return combined in a way that is easy to accumulate but all the more complicated to grasp later on.