Intro

Code review is systematic quality assurance for code (Fagan 2002). Code reviews should be short! Best practices from a 2006 Cisco study:

  • Lines of code (LOC) under review should be less than 200, not exceeding 400, as anything larger overwhelms reviewers and they stop uncovering defects.
  • The total review time should be less than 60 minutes, not to exceed 90. Defect detection rates plummet after 90 minutes of reviewing.

Pull requests should be small! This dovetails with our recommendation for more frequent, smaller commits. More information is available here:

Div I project

  1. Submit a function using the Markdown template given on GitHub Classroom
    • Tell us what the function is supposed to do
    • List any dependencies
    • Describe any arguments
    • Describe the expected result
    • Show us 2-3 examples of how to use the function
    • Provide a few examples verifying that the function works as intended
  2. We will review your code and:
    • edit it for style
    • edit it for readability
    • show you where it breaks
  3. You will write a short reflection about the experience

Div I grading rubric

Criteria Eight Nine Ten Eleven
Documentation Code is poorly documented. Code is only partially documented and only works in ideal cases. Code is mostly documented and mostly works as expected. Code is fully documented and always works as expected.
Robustness Errors are easy to generate. Function returns objects of different type than specified. Function can be broken easily but works for sensible inputs. Function is robust to unexpected user input.
Usefulness Function is actually less effective than existing functionality. Function is hard to use because it’s not clear what it is supposed to do, or how it works. Function adds nothing to existing functionality. Function makes only incremental improvements over existing functionality. Purpose of function is clear. Function solves a real problem that is not easily solved using existing functionality.
Sophistication Function requires only basic knowledge of R and lacks ambition. Function uses loops when vectorization would be simpler. Function leverages vectorization but uses loops where iteration would be simpler. Function makes use of vectorization and iteration without using loops.
Criteria Zero One Two
Package idea No idea expressed Vague, implausible idea expressed Reasonble idea expressed
Growth No reflection Reflection is not honest Reflection is honest and thoughtful

Div II project

  1. Create a minimally viable R package that:
    • contains at least one fully-documented function OR data set
    • has a README that shows how to use the package
    • installs via remotes::install_github()
    • passes R CMD check (no errors, no warnings, minimal notes)
    • depend on at least one existing CRAN package
    • has at least one test (e.g. devtools::test())
Criteria Seven Eight Nine Ten
ERRORs, WARNINGs, or NOTEs thrown by R CMD check 5 or more 3-4 1-2 0

Div III project

References

Fagan, Michael. 2002. “Design and Code Inspections to Reduce Errors in Program Development.” In Software Pioneers, 575–607. Springer. https://doi.org/10.1007/978-3-642-59412-0_35.