Chunks of code can be considered as R islands in a sea of markdown. A code chunk is opened with the following token:

```{r}

And it is closed with:

```

Within these signs, the PC knows that everything has to be taken as R code, and everything has to be interpreted accordingly. The most prominent example to understand what the implications are is this one, within a code chunk, the ## token will not be taken as the start of an h2 headline, but rather as the start of a commented line.

It is quite a common practice when developing rmarkdown documents to insert the first setup chunk where preliminary operations are performed and general options are defined. These operations are mainly:

• Loading libraries
• Data loading
• Preliminary data treatments
• General variable initialization
• Code chunk options setting

While the first four should not be obscure to you, let me spend some more time on the last one. Code chunks come with a full list of possible options to be set in order to express the behavior we want them to follow with regards to some specific aspects. Let's have a look at the most used ones:

• name: Every chunk can have a name, which is useful when dealing with debugging activity and other, more advanced, operations. Be aware that every chunk must be provided with a unique name.
• eval: This decides whether the code chunk should actually be run or not.
• echo: This specifies whether the code itself should be printed out.
• warning: Used to define whether hypothetical warnings coming from code execution should be printed.
• error: This is the same as warning but is only related to errors.
• include: This decides whether the output coming from the code running should be included within the document. This is different from eval in that not evaluating a chunk will necessarily result in its output not being in the report, but not including the output will not stop it from being executed. 

You can set all of these options in two ways:

• Once for all chunks, usually by writing something like the following within the setup chunk: knitr::opts_chunk$set(echo = FALSE)
• Individually for each chunk, by inserting your set within the opening brackets of a specific chunk

In doing so, you should be aware that the nearest command will override the most farthest one; so, writing in the brackets of a chunk eval=TRUE will make the code of the chunk run even if a general knitr::opts_chunk$set(eval = FALSE) code was stated somewhere earlier. 

That said, we can open our first chunk, naming it setup, since we are going to employ it to set up the general parameters and load the needed libraries: 

```{r setup, echo=FALSE} 

Let's actually write down our setup chunk:

```{r setup, include=FALSE}

library(dplyr)
library(ggplot2)
library(tidytext)
library(tidyr)
library(igraph)
library(ggraph)
library(wordcloud)

knitr::opts_chunk$set(echo = FALSE)
load("data/corpus.rdata")

corpus %>% 
 filter(!grepl(c("date of foundation"),text)) %>% 
 filter(!grepl(c( "industry"),text)) %>% 
 filter(!grepl(c( "share holders"),text)) -> comments

corpus %>% 
 filter(grepl(("date of foundation+"),
 text)|grepl(( "industry+"),
 text)|grepl(( "share holders+"),
 text)) -> information

```

As you see, we basically load our libraries, set the echo option to false, and load the corpus object we have saved from our analyses. We then split it into comments and information to have those two data frames ready for subsequent chunks.

And this last statement leads us to the last relevant concept I would like to teach you about code chunks, code chunks are like islands but are not isolated. You can imagine some kind of underground system of communication that lets the islands share information among themselves, at least from top to bottom. This means that if I create a data frame or any other kind of object within the first chunk, I will have it available within subsequent chunks. The opposite will not hold true, just as it will not hold true in a regular R script since the code is read and evaluated from the PC from top to bottom.