# Single Responsibility  Functions

Many people understand the [Single Responsibility Principle](https://en.wikipedia.org/wiki/Single-responsibility_principle), but very few pay attention to how it affects whether function (and methods) should return something. In this blog post, I'm looking at a case for taking that principle to the "extreme" and looking at how functions could be written to only ever have a single reason to change. 

## Checking for Success

A common thing return statements can help do is verify that operations were successful by returning boolean values, see this example:

```
if (UpdateUser(user)) {
    if (SendEmail(user.email)) {
        // log operation
    } else {
        // retry sending email
    }
} else {
    // log failure
}
``` 
Returning `false` only says the functions failed but it doesn't say why., this is what [exceptions](https://en.wikipedia.org/wiki/Exception_handling) are for. If the functions `UpdateUser` and `SendEmail` were rewritten to throw exceptions, we eliminate the need for the conditionals, make the whole code easier to read and handle errors better.

```
try {
    const createdUser = UpdateUser(userData);
    SendMail(user.email):
} catch (e) {
    // log error
}
```
This implementation is easier to read, allows for better error handling (Exceptions should contain error messages) Writing the functions this way brings up the question, "What then (if anything) should the `UpdateUser` and `SendMail` functions return?"

## Command Query Separation

Taking the Single Responsible Principle to the extreme in this case, let's employ [CQRS](https://en.wikipedia.org/wiki/Command%E2%80%93query_separation). CQRS states that a method or function should either be a _Command_ that changes state or a _Query_ that returns values, but never both.  In this light, the `UpdateUser` function should only ever update a user with no side-effects and return nothing, same thing with the `SendMail` function.

```
try {
    UpdateUser(userData);
    const user = GetUser(userId);
    SendMail(user.email):
} catch (e) {
    // log error
}
```
This makes everything a whole lot clearer and more consistent. It's easy to know exactly what a function does (knowing that it doesn't do anything else). Satisfying the [Principle of Least Astonishment](https://en.wikipedia.org/wiki/Principle_of_least_astonishment) as there are no side-effects and functions/methods do not return needless information.

## Conclusion

CQRS and [SOLID](https://en.wikipedia.org/wiki/SOLID) are some important tested and trusted principles. Ultimately, stick to what works for your use case.