{"id":2374,"date":"2018-10-24T05:27:58","date_gmt":"2018-10-24T04:27:58","guid":{"rendered":"https:\/\/www.entropywins.wtf\/blog\/?p=2374"},"modified":"2019-03-01T16:32:43","modified_gmt":"2019-03-01T15:32:43","slug":"readable-functions-minimize-state","status":"publish","type":"post","link":"https:\/\/www.entropywins.wtf\/blog\/2018\/10\/24\/readable-functions-minimize-state\/","title":{"rendered":"Readable Functions: Minimize State"},"content":{"rendered":"

Several tricks and heuristics that I apply to write easy to understand functions keep coming up when I look at other peoples code. In this post I share the first of two key principles to writing readable functions. Follow up posts will contain the second key principle and specific tricks, often building on these general principles.<\/p>\n

What makes functional programming<\/a> so powerful? Why do developers that have mastered it say it makes them so much more productive? What amazing features or capabilities does the functional paradigm provide to enable this enhanced productivity? The answer is not what you might expect if you never looked into functional programming. The power of the functional paradigm does not come from new functionality, it comes from restricting something we are all familiar with: mutable state. By minimizing or altogether avoiding mutable state, functional programs skip a great source of complexity, thus becoming easier to understand and work with.<\/p>\n

Minimize Mutability<\/h3>\n

If you are doing Object Orientated Programming<\/a> you are hopefully aware of the drawbacks of having mutable objects. Similar drawbacks apply to mutable state within function scope, even if those functions are part of a procedural<\/a> program. Consider the below PHP code snippet:<\/p>\n

function getThing() {\n    var $thing = 'default';\n    \n    if (someCondition()) {\n        $thing = 'special case';\n    }\n    \n    return $thing;\n}<\/pre>\n
This function is needlessly complex because of mutable state. The variable $thing<\/code> is in scope in the entire function and it gets modified. Thus to understand the function you need to keep track of the value that was assigned and how that value might get modified\/overridden. This mental overhead can easily be avoided by using what is called a Guard Clause<\/a>:<\/p>\n
function getThing() {\n    if (someCondition()) {\n        return 'special case';\n    }\n    \n    return 'default';\n}<\/pre>\n
This code snippet is easier to understand because there is no state. The less state, the less things you need to remember while simulating the function in your head. Even though the logic in these code snippets is trivial, you can already notice how the Accidental Complexity<\/a> created by the mutable state makes understanding the code take more time and effort. It pays to write your functions in a functional manner even if you are not doing functional programming.<\/p>\n
Minimize Scope<\/h3>\n
While mutable state is particularly harmful, non-mutable state also comes with a cost. What is the return value of this function?<\/p>\n
function getThing() {\n    $foo = 1;\n    $bar = 2;\n    $baz = 3;\n\n    $meh = $foo + $baz * 2;\n    $baz = square($meh);\n\n    print($baz);\n    return $bar;\n}<\/pre>\n
It is a lot easier to tell what the return value is when refactored as follows:<\/p>\n
function getThing() {\n    $foo = 1;\n    $baz = 3;\n\n    $meh = $foo + $baz * 2;\n    $baz = square($meh);\n    print($baz);\n\n    $bar = 2;\n    return $bar;\n}<\/pre>\n
To understand the return value you need to know where the last assignment to $bar<\/code> happened. In the first snippet you, for no reason at all, need to scan up all the way to the first lines of the function. You can avoid this by minimizing the scope of $bar<\/code>. This is especially important if, like in PHP, you cannot declare function scope values as constants. In the first snippet you likely spotted that $bar = 2<\/code> before you went through the irrelevant details that follow. If instead the code had been const bar = 2<\/code> like you can do in JavaScript, you would not have needed to make that effort.<\/p>\n
Conclusion<\/h3>\n
With this understanding we arrive at two guidelines for scope in functions that you can’t avoid altogether in the first place. Thou shalt:<\/p>\n