One of the many things I’ve learnt from the Clean Code book is about the evils of output variables.<\/p>\n\n\n\n
Functions can take arguments and can return values. An output variable is one of those arguments that the function uses to give a result by changing its value instead of, or in addition to, the function\u2019s normal return value. Although this sounds really handy, it comes with some issues.<\/p>\n\n\n\n
As mentioned before, output variables may seem innocent, and even good, but there are a number of reasons why they should be avoided. Here’s why.<\/p>\n\n\n\n
In some of my previous articles I’ve mentioned something that is not always recognised: software developers spend most of our time reading rather than writing code.<\/p>\n\n\n\n
When we use output variables, we are hiding information from whoever needs to read our code. Following the code becomes harder, as we force people to see how functions are implemented in order to understand the code (or check the documentation if this is a library) to find out that we’re using the argument to return data. And, on top of that, we have to remember all that while we read the rest of the code.<\/p>\n\n\n\n
Attempts at addressing this issue by using clear variable names (for example, Another problem is when two or more variables point to the same object. And, in fact, I find that this is one of the worst types of bugs to have to deal with, as the code seems perfectly fine even though it’s not. Changing a value this way can lead to unexpected results. Take this code, for example:<\/p>\n\n\n Here, both functions do their job correctly, but the interaction produces an invalid value. Taxes should be applied to the original price, before the discount, and the discount should be applied to the original price, without taxes. However, these functions update the value that the other uses to make their calculation, so the final result is incorrect.<\/p>\n\n\n\n If you are still wondering what the customer should be really charged, I’ll show the answer at the end of this article \ud83d\ude42<\/p>\n\n\n\n Testing a function that returns a value is simple: we call it, compare the return value to what we expect, and voil\u00e0:<\/p>\n\n\n To be fair, tests tend to be more complex in real life. But that said, testing a function’s output variable response adds even more work, as we need to set up the argument, then call the function, to finally check if it changed the way we wanted:<\/p>\n\n\n That\u2019s more steps and more chances to mess up, and it becomes worse if the function also returns data in the standard way.<\/p>\n\n\n\n Another issue is that functions with output variables don\u2019t work well together. Consider the functions in the example below. If these functions used output variables, we\u2019d have to break the code into multiple steps and keep track of extra variables:<\/p>\n\n\n Here, we have several lines and temporary variables to be aware of when working with this code. We also have to remember which arguments are being read, which are being written, and in what order.<\/p>\n\n\n\n However, if we had a bunch of functions that just return values, we could chain them easily:<\/p>\n\n\n Here, each function returns its result, and we simply pass it to the next function. <\/p>\n\n\n\n Even though output variables can cause problems, they can be very useful sometimes, for example, when performance is critical, and creating new objects or passing pointers is the difference between success and failure.<\/p>\n\n\n\n Many programming languages use output variables in their built-in functions\/libraries, like encoding and I\/O operations. This is not by chance, but to allow building performance-critical applications if a system requires it. Sometimes, these built-in features are so idiomatic that we could even argue that using them is not particularly problematic.<\/p>\n\n\n\n A word of caution though: I’ve witnessed over and over how most developers try to prematurely optimise their code at the expense of readability and maintainability, without even knowing if that was even needed.<\/p>\n\n\n\n Please, if you “think” your code needs to be optimised, do yourself a favour and make sure before making any changes. I recommend reading this other article for further thoughts on this topic:<\/p>\n\n\n\noutValue<\/code>) are welcome, but are not really a solution. When reading the code, we may easily miss this if we’re not expecting an output variable, even if the name is clear. And it’s not unheard of to have changed a function and forgotten to change some variable names that are no longer used as output variables.<\/p>\n\n\n\nCan introduce bugs that are hard to detect<\/h5>\n\n\n\n
\ndef apply_discount(out_cart)\n out_cart[:total] *= 0.9 # changes the argument\n out_cart[:total] # also returns a value\nend\n\ndef apply_tax(out_cart)\n out_cart[:total] *= 1.1 # changes the argument\n out_cart[:total] # also returns a value\nend\n\ncart = { total: 100 }\n\n# returns 110, cart[:total] now 110\ntotal_after_tax = apply_tax(cart)\n\n# returns 99, cart[:total] now 99\ntotal_after_discount = apply_discount(cart)\n<\/pre><\/div>\n\n\nMake Testing Harder<\/h5>\n\n\n\n
\ndef double(x)\n x * 2\nend\n\nputs double(4) == 8 # test in one line\n<\/pre><\/div>\n\n\n
\ndef double!(out_var)\n out_var[:value] *= 2\nend\n\nvar = { value: 4 }\ndouble!(var)\nputs var[:value] == 8 # need to check the updated state\n<\/pre><\/div>\n\n\nPrevents Chain Calls<\/h5>\n\n\n\n
\ndata = nil\nread_data(data) # sets 'data'\n\ncleaned = nil\nclean(cleaned, data) # sets 'cleaned' from data\n\nresult = nil\ntransform(result, cleaned) # sets 'result' from cleaned\n<\/pre><\/div>\n\n\n
\nresult = transform(clean(read_data))\n<\/pre><\/div>\n\n\n
Dancing With the Devil<\/h3>\n\n\n\n