Member-only story
5 Anti Patterns to Avoid When Writing Code in a Functional Programming Language
Use case examples with Scala
Functional programming languages have gained so much traction in these past few years.
Many people can see the benefit of writing code that contains features such as functions as a first-class citizen. They embrace immutability in a concurrent environment, running heavy computed tasks without worrying about some concurrency issue, and love to write generic code to be as DRY as possible.
I saw this as a good sign that functional programming language is becoming mainstream again. However, one of the hard parts of writing code in a functional programming language is its design pattern and anti-pattern, which are different from a regular programming language.
I often see engineers writing in a large codebase that I classified them anti-pattern. I had also committed to these anti-patterns when I initially wrote a production-ready application in a functional programming language. Since then, I have read many books about functional programming design patterns and books that have helped me create a more maintainable code.
Overly nested anonymous callback function.
An anonymous function can be good for code-reusability. However, too much anonymous function can hurt the eyes of those engineers who want to extend the functionality. Although DRY is the way to go, sometimes duplication is better than the wrong abstraction.
I have touched codebase where engineers will write a heavily concise and abstract method. The code is something like this:
Can you tell me what the definition of buildRunner is?
Then, this buildRunner is used in all action operations like authorize, capture, and void in the payment processor. I look at it for two days to finally understand what it is trying to do.
