John Carmack (founder of many first 3D games like Wolfenstein 3D, Doom, Quake) wrote an interesting article on functional programming, and this article further summarizes it, and utilizes examples of how this practice can be applied to the code.
Functional programming (FP) is a paradigm, and you do not need a particular language to use FP. We do not necessarily need to understand the history, or how particular languages like Scheme or F# works. In this article, we will study how we can apply this paradigm to C or C++ code base.
As a simple example, consider the following code, and note the following:
increment_and_wrap() accesses its own internal state (m_capacity)
One way that you can guarantee that you are applying the FP paradigm is to use const functions, which by definition imposes that the functions are pure and that they do not modify an internal state. Furthermore, also realize that non-const functions are also not thread-safe, and:
the ability to incrementally poke and prod objects into unexpected states is indeed a significant source of bugs
Pure functions accept parameters, and return one or more computed values. They do not operate on any internal state such as the m_ member variables of a class, and they do not read or update a global state, nor do they maintain any internal state.
De-coupling functions from specific internal variables promotes code re-usability, makes the code easier to read, and helps facilitate testing.
With C++ classes, you may be tempted to write “impure” functions because a class fundamentally helps you hide the data as private members, and it may seem natural that class functions can access the private members directly.
Whether it is C or C++ code base, the FP paradigm should be encouraged.
FP helps decouple the code, and allows the code to be more reusable
FP helps read the code more clearly as you can see the parameters, and output easily (facilitates better code reviews)
FP eases the unit-test development
John Carmack’s conclusion was:
No matter what language you work in, programming in a functional style provides benefits. You should do it whenever it is convenient, and you should think hard about the decision when it isn't convenient
Inspired from John Carmack’s article:
Survey your code-base and identify pieces of code that can use FP paradigm
You should be easily able to spot code that can improve its readability and refactoring into a pure function would better describe the inputs and outputs, and hence make the code easier to read
Refactor code into pure-functions to realize the benefits, such as: