[kalaksi]

1. The pipeline is simple to split or cut entirely, though. No reason to grow it into a monstrosity, but many reasons to not do it. This problem sounds similar to growing a function too much.

2. I agree in general when talking about more complex operations. Simple transformation and filtering rarely needs intermediate variables for readability or debugging. And the naming of result variable already describes the final collection.

3. Never had to deal with this kind of code but I haven't used Kotlin.

[kubik369]

1. Yes, you hit the nail on the head. It basically requires people to be more cognisant of this. However, I think telling people to break stuff out into intermediary variables is much easier to argue for than whether the function is getting a bit too long.

2. Yes, easy filterings usually don't need to be broken down/named, but it really depends. At the very least, if the culture is to name intermediary values, you might accidentally get useful information from the variable names even if people weren't diligently writing explanatory why comments.

3. This isn't Kotlin related, it is just that if you do not have a language/codebase with branded types (or some type system property I don't know the name of), the type system might only infer the base primitives of the result, ending up with stuff like the type I mentioned.