C# – better term for “functional method chaining”

ccoding-stylefunctional programmingmethod-chaining

I'm writing a C# style guide for my team and I'm trying to describe the benefits of side-effect-free functional-style methods. I want to include online references to back up the suggestions, but I can't seem to Google the kind of functional method chaining I have in mind.

When I think "method chain", I imagine something like this (in Ruby)

userInput.chomp.downcase.split(",").map(&:to_i)[3].to_s(16)

where each method returns a new object (maybe even of a different class) and everything is side-effect-free, so it's like composing functions in a functional language. Writing function-like methods make these kinds of chains very easy to construct and, in my experience, greatly simplify code.

But when I Google "C# method chaining", I keep finding stuff like this

myObj.AddItem(mItem).AddItem(mItem2).AddItem(mItem3);

where each method mutates and returns the receiver. This is pretty much the opposite of functional programming and, if anything, is the kind of thing I want to discourage on my team. Even when I Google "C# functional method chaining", the top result is blog post about StringBuilder, which relies entirely on the side-effects of each method call!

Is there a different term for this than just "method chaining"? Or, even better, is there some place that documents the benefits of this style?

Best Answer

The commonly used name for this is a Fluent Interface. In the functional world, it's simply Function Composition.

But outside of the functional world, it has few good applicable uses. Yeah, it's great for enumerables. And it's workable for date/times. But mostly it's a vile construct that is abused to create code that is overly clever, or "readable" (but only for a select few familiar with your weird in-house fluent library).

Side effect free functional-style methods (pure functions especially) do have huge benefits around testability, reusability, robustness, concurrency, performance... focus on those, not this syntactic fluffery.