5 kinds of side-effects

Before we stat

We usually talk about side effects in the context of functions or expressions. To keep it simple I will mostly refer to functions in this article, but keep in mind that similar rules also applies to expressions.

Pure functions (without side effects)

Before we discuss all sources of side effects let’s take a quick look at the pure function that doesn’t have side effects:

Calling the sum function multiple times with the same arguments a and b will ALWAYS produce the same result — sum of a and b. This function does not access or modifies any variables outside its body, so we say it does not have side effects.

Side effects are closely related to functional programming paradigm where the ultimate goal is to have only pure functions. Pure functions are much easier to test (output only depends on input) and thread-safe. In general, it’s good practice to have as many pure functions as possible. Working with OOP we learned to create many impure functions and sometimes it may be tricky to spot the difference between pure and impure function.

Impure functions (with side effects)

We say that function has side effects when it has observable interaction with the outside world. There are few ways to make our function impure. Our goal is to make our functions pure, so these are scenarios should serve as a warning for you. Let’s examine few examples of side-effecting (impure) functions.

Modify variable outside of function

This is one of two most popular groups of side effects. The first case is data persistence where we store data passed to a function.

Just to clarify keep in mind that side effect is not a necessary bad thing and sometimes they are useful (especially outside functional programming paradigm).

Another example of side effect is modifying property of an object e.g. showing or hiding progress bar.

Also, logging is treated as a side effect.

Retrieve variable from outside function

Second most popular group side effects are retrieving the value from outside the function scope. The simplest scenario is to return the object that is stored in a class field.

Functions that return value is that is retrieved from static classes also fit into this category.

Both of above function return value that was retrieved from outside the function. Each time you deal with network requests, disk operations or user interference your function will probably have the side effects e.g. side effect of saving/loading data from/to server is network request.

Mutate argument

Another side-effecting scenario is modification of object passed as an function argument.

Calling this function multiple times with the same Patient instance will lead to different output because we modify value outside the function.

Throw an exception

Not so obvious but definitely side effect is an exception thrown by a function.

Call other side-effecting function

Last and sometimes hard to spod side effect occurs when we call another side-effecting function.

Function sumMe is not pure because it is calling sum function that has side effects (logging).

Extra: side effects and RxJava

Side effects are also present in RxJava. They may be useful for logging, data persistence or updating the UI. They exist in form of operators that are executed upon operators chain but do not modify the chain.

Different operators will be avialable depending on reactive type (Observable / Flowable / Single / Completable / Mabye).

Summary

As you can see some side effects are quite easy to spot and some of them are tricky. A good sign that our function us impure (has side effect) is that it doesn’t take any arguments it doesn’t return any value.


If you liked this article please click the 👏 below to recommend. I would love to hear your thoughts in the comment section. Thanks a lot!