Thread by @neilgcurrie

Struggling with functions in R?

You're not alone!

In this thread, I'll show you some tips and tricks for upping your function-writing game.

Let's dive in...

#rstats #coding #datascience

Functions are blocks of code organised together which perform a specific task.

R comes with many built-in functions which we can add to by downloading fantastic packages.

However, writing your own functions is where the true power of R lies - though it can be confusing.

1/16

In this thread I will cover:

1. When to write functions
2. How to write functions
3. Tidy evaluation
4. Passing multiple arguments with ellipsis ...
5. Error handling arguments
6. Side effects

2/16

A question I hear from newer coders is when should I actually write a function?

I follow some basic rules of thumb to decide went to turn code into a function, though it isn't an exact science.

1. The rule of 3.
2. The rule of organisation
3. The rule of testing.

3/16

1. The rule of 3

If I repeat some code 3 or more times, or I expect to, then I write a function.

Many errors enter code from copy + paste or retyping.

By calling a function many times you reduce the chances of this error, and to update code you need only change one part.

4/16

2. The rule of organisation

Often code can become long and complex.

In these cases I will split code into functions where I think this will aid readability and manageability.

Often the inside of a big for loop is a good candidate.

5/16

3. The rule of testing

Sometimes code contains calculations or small chunks that are crucial to the program or are logically complex and I want to test them individually.

In these cases I write functions.

To learn more about unit testing have a look here:

6/16

Arguments are the variables which are passed into the function.

They can be matched positionally or by name.

You can create default values for your function using = in the function definition.

7/16

If you have used the tidyverse you will have come across tidy evaluation.

Tidy eval allows us to use code like select(data, x) instead of select(data, "x").

But how can we take advantage of that behaviour with our own functions?

8/16

To use tidy eval in our own code we use double curly brackets {{arg}} to wrap the argument.

If the argument relates to the left hand side (i.e. a name) of a tidyverse function like mutate we also need to use :=

9/16

Arguments are often a great source of errors.

Checking for these errors and telling the user what they should do is great practice.

Some good checks of arguments are type, structure and validity of values supplied.

Be proportionate and try to anticipate likely errors.

10/16

The ellipsis allows functions to take any number of arguments.

Some good examples are the paste and print functions.

In our own functions they are especially handy when we write wrapper style functions.

11/16

When using ... in functions it is good practice to place it after your main arguments but before any additional arguments with default values.

This makes supplying the ellipsis arguments easier when using the function.

12/16

We return variables from functions using the return function or, if missing, R will return the last evaluated object.

But sometimes when we write functions we aren't interested in the return value but its side effects e.g. when creating a plot or outputting data.

13/16

In these cases it is good practice to return the first argument unmodified.

Wrap it in the invisible function so it doesn't clutter your console by printing.

You could easily put this in a pipeline now.

14/16

To recap:

There are several rules of thumb to decide when a function is needed.

Some tricks like tidy eval and ... make your functions more powerful.

ALWAYS write error handling.

The return value isn't always important. Sometimes the side effect is the main event.

15/16

Thanks for reading, if you liked this thread follow me @neilgcurrie for mainly R and data tweets.

Website:

shoogle.co

YouTube

youtube.com/@shoogle

Code:

github.com/neilcuz/thread…

16/16