R Tutorial: Optional directories

You have now seen everything that you have to include, but you might remember that we said there were other things that you could include, like data and vignettes. There are many other components that you can include in an R package. The most common include data vignettes and unit tests. Others include compiled code such as C, and even translations for messages. In the past it was also common to include demo code, although they have.

Mostly been replaced by vignettes.

You will see more about test later, so we'll leave that for now. But all of these can be easily incorporated into your packages with simple use functions.

Let's start with an example of data.

There are a number of ways you can include data, but as a simple example, let's assume you want to include data for the end user to work with. Data is stored in the data directory as an R data file you can call the Use Data function. To create this rdata file from an R object, use data needs to know the name of the object and the.

Location of the package.

If you want to create a vignette, which you can think of as a user guide, you can use usevignette in a similar way. This function will create a directory called.

Vignette and create a template vignette for.

You to edit with the name that you provide. Dev tools will create an R markdown template for you. So if you're already familiar with R.

Markdown, there is little else you need to know.

DevTools will include a special header that you should leave as is. That will ensure that R identifies your vignette. You can write as many vignettes as you want using the usevignette function each.

Time to create the template.

When you create an R package, it.

Must follow the standard structure. You can't just create any directories you want, or your package won't build.

So what does this mean for the.

Code in our R directory?

There is in fact only a single rule around this. You can't create sub directories. Otherwise you can have as many or as few R files as you want. Generally, you should avoid having everything in one script. For a small package, you might want to have one file per function with.

A file name reflecting the function name.

But as a package gets larger, it's common to see similar functions grouped together. Personally, I tend to end up somewhere in between, with large functions in a.

File of their own and smaller utility.

Functions grouped together with other similar functions. Now it's your turn to try including.

Some of these optional elements.