Introducing functional calisthenics
TL;DR
Object Calisthenics helps people to become better Object-Oriented programmers and as someone new(ish) to the functional world I wondered if there were an equivalent set of rules that would help me become a better functional programmer, so I asked the people at SoCraTes UK 2015:
- Side effects can only occur at the top level
- No mutable state
- Expressions not statements
- Functions should have 1 argument
- No explicit recursion
- Maximum type-level abstraction
- Always use infinite sequences
- No "if"
- Name everything
- Use intermediates
- Don't abbreviate
Want to read more?
What are Functional Calisthenics? They are derived from Object Calisthenics, these rules that you can apply to make your object-oriented code better by applying strict rules in what you can and cannot do. These strict rules force you to think differently about how to write your code, e.g. the rule No getters of setters will often lead to people thinking If I can't get at the internal state using a getter, how can I test that the current state is correct? I was wondering whether there was something similar that I could use as a training exercise to improve my functional programming and escape an "object-oriented mindset".
So, I asked the wonderful community at the SoCraTes UK 2015 conference about them, there was a huge amount of interest and a lot of people enthusiastically helped to come up with these initial thoughts on our Functional Calisthenics.
Side effects can only occur at the top level
We want the majority of our code to be pure functions and in order for that to be the case they cannot depend on anything that is impure. This means we should pull the impure functions up to the top level and isolate them as much as possible from the rest of the code. This can include:
- User interaction
- Database access
- API calls
No mutable state
This is very close to the Side effects can only occur at the top level rule but we can go further than just creating pure functions, we don't want to mutate state within a function either, e.g. do not re-use variables (if your language allows) as this has a negative impact on code readability and any mutable state could potentially result in an unintended consequence.
Expressions not statements
This is a kind of extension of the No mutable state rule, if we are calling a function that does not return anything then we are probably expecting that some mutable state will be changes as a part of this call and the function will not be pure. If we are aiming for purity then we should only be using functions that take return values.
Functions should have one argument
This is one that is probably causing a fair amount of debate, but we should be using restricting the number of arguments that a function can take, a function with a large number of arguments smells of a single responsibility principle violation. Currying provides us with the ability to reduce long argument lists to a series of functions that all take one parameter.
No explicit recursion
Prefer separating the method of recursion away from the logic that you are trying to execute.
Maximum level of abstraction
Functions should take the highest level of abstraction possible, e.g. if List is a special case of Enumerable then the function should take Enumerable.
Use infinite sequences
If you function takes, or returns, a sequence of data then write the function in a way that does not exclude infinite sequences, allow for tail recursion etc.
No if
Avoid using if statements where possible. As Samir said
"if" is just a special case of pattern matching anyway
Name everything
We should provide named types for primitives including tuples and we should avoid anoymous functions and lambdas.
Use intermediate variables
Avoid chaining function calls, extract into intermediate variables.
Don't abbreviate
Let's be fair, we've all seen functional code with functions like f(), we're not in the dark ages people and we can afford to use more descriptive names to help those who come along later to understand the intent of the code.
What's next
Thse are all preliminary ideas that could help people learn and grow their knowledge of functional programming, they are barely 9 hours old as I write this and we have had our first tentative steps in applying these rules to a code kata. The next step is to try Functional Calisthenics in code katas, see what works, what doesn't are there other rules that would help produce better functional programmers. The discussion is just beginning.
Thanks
I could not have come up with these rules without those who attended my session at the SoCraTes UK 2015 conference, I may have had an idea but they have taken the concept and fleshed it out to where we are now and hopefully together we will continue to develop these ideas for the benefit of the community.