Code Review

Melanie Frazier & Julie Lowndes

rOpenSci Community Call

October 16, 2018

​

OUR SITUATION

Global Ocean Health Index calculated every year (since 2012)!

​

Work in R

​

Mostly write code to wrangle and analyze data

OUR SITUATION

​

​

We review our code every year (4-6 people)

​

We’ve had a chance to determine what works

​

IDEAL vs. REALITY

THE BEST: Have someone independently

recreate code

2nd BEST: External review of all code

​

BUT: Time is an obstacle!

What to do!?

​

1. MAKE IT EASY TO SHARE

​

• Github repos: store all code and data
• Github issues: report, questions, reference materials, etc.
• here package: standardize file paths (previous: ~/github/)

2. PROMOTE COMMON PRACTICES

• Weekly Team Meetings: discuss coding

(tidyverse, etc)

• Protocols for file organization
• Put code in Rmds: flow between documentation & code

​

We prioritize documentation over code optimization

(we are sometimes guilty of unnecessary loops, cut-and-paste, etc ….. oh-well!)

3. ERROR AVOIDANCE TRAINING

• Break code into manageable chunks

(no run-on dplyr chains)

• Techniques to check data esp. at danger points (i.e., joins, NAs)
• Write warnings/errors and/or document expectations when checking data

(e.g., “# should be length 0”)

4. REVIEW AS A PROCESS

We post results (in near real time as well as for final review) to a Github issue:

• Do results make sense
• Explore NAs
• Explore outliers

5. STRATEGIC CODE REVIEW

​

• Restart R Session and rerun code
• Make sure it still runs!
• Review warnings
• Compare results with previous runs

git2R to pull data from previous commits

• External review of some code (~ 50% for us)
• Complex analyses
• New team members

​

LAST THINGS

Work to create an environment where mistakes are expected and OK (Parker 2017) !

​

Start of additional resource:

https://rawgit.com/OHI-Science/ohiprep_v2018/master/Reference/CodeReview/code_review.html