Best Practices for Studying someone elses Functions

[realhiphop]

I'm in the process of creating my first package. In a lot of situations, I get ideas from someone else's function, and attempt to utilize how they went about doing something from their code.

Is there a suggested way to systematically review someone else's code in order to understand the arguments, and the steps that get to the result of the function?

I currently fork the repo, and manually execute the code line by line. It gets a little more complex with functions embedded within functions.

Thanks in advance, and look forward to suggestions!

[realhiphop]

My idea is to create an RMarkdown file and break out the code line by line. I would then print the objects to see what each line of code does. Does anyone else do that? Is there a way to print named objects by default in RMarkdown? Right now my code is taking each named object and then using

head(df, 5)

[EconomiCurtis]

This doesn't answer your specific question, and you've nearly certainly seen this already, but a great way to get started with best practices for R package development is Hadley's

R packages by Hadley Wickham - Packages are the fundamental units of reproducible R code. They include reusable R functions, the documentation that describes how to use them, and sample data. In this section you’ll learn how to turn your code into packages that others can easily download and use. Writing a package can seem overwhelming at first. So start with the basics and improve it over time. It doesn’t matter if your first version isn’t perfect as long as the next version is better.

[realhiphop]

Thanks. Hadley's book was/is a huge help.

[jdblischak]

@realhiphop

I currently fork the repo, and manually execute the code line by line. It gets a little more complex with functions embedded within functions.

@realhiphop How exactly are you manually executing the code line by line? Are you using the interactive debugger? When I want to deeply understand a function in another package, I use debug() and browser() to enter into the debugger. browser() is especially useful for investigating nested functions.

[realhiphop]

Based on your response, I'm guessing that I've been creating a lot of manual work for myself. Here's an example of my process. Let's imagine that the arguments are variables required to build the URL.

# Sample Function
scrape_website <- function(movie_genre = "Action", stars = "4"){
base_url <- "http://www.something.com"

built_url <- 
    glue::glue("{base_url}?{movie_genre}&{stars}") %>% 
    as.character()

page<- built_url %>% read_html()

I think you get the point. I would generally take the function arguments and write them in code, then run each line of code individually. I would then go into each object and see what changed, etc. Using glimpse, or view.

# Function Inputs
movie_genre = "Action"
stars = "4"

Sounds like this isn't the right approach?

[jdblischak]

@realhiphop

I would generally take the function arguments and write them in code, then run each line of code individually. I would then go into each object and see what changed, etc. Using glimpse , or view .

@realhiphop This approach works well for investigating a single function. But as you mentioned in your original post, if you want to investigate more complex situations, I'd recommend taking the time to learn how to use the interactive debugger. Fortunately RStudio enhances the experience. It will show you which line you are currently on, and the Environment pane automatically updates to show whichever objects are defined in the environment you are currently debugging. It also has shortcuts that allow you to conveniently use the R debugging tools, but I'd recommend using them manually first so that you better understand what the RStudio debugging tools are doing.

I'd recommend learning how to use the functions browser(), debug(), and traceback(), as well as setting the option options(error = recover).

My biggest tip is that when you're in the debugger, you can always type help to see the list of available commands:

> help
n          next
s          step into
f          finish
c or cont  continue
Q          quit
where      show stack
help       show help
<expr>     evaluate expression

Some resources:

• Debugging in Advanced R

• Debugging techniques in RStudio by @amanda.gadrow

• Debugging with RStudio by @jonathan

[realhiphop]

Thanks, sounds like I have some reading to do. I marked your response as a solution since I think it will lead me there.