RGP Coding Tips¶

• RGP Coding Tips
• Design Tips
• Debugging Tips
• Debugging RGP C Code
• Debugging RGP R Code
• Coding Style

This page collects tips on design and debugging of the R and C code making up RGP. It also has a section on RGP's typographic source code style (important) and RGP's technical design philosophy (much more important). Please also see the tutorial on How to Contribute to RGP.

Design Tips¶

• Please try to use terms and concepts consistently and in accordance to the RGP Glossary. Consistent terminology makes your code much easier to read for everybody.
• Keep in mind that RGP is meant as a toolbox, not a monolithic system. Always strive for small and general functions. Do not introduce custom datatypes when a combination of built-in datatype could does the job.
• Use mutable variables sparingly, preferably only when doing so
  gives significant performance gains in a critical code path. Avoiding mutable state most likely leads to a cleaner design that has fewer bugs and is easier to understand and test. See Why Functional Programming Matters by J. Hughes for a good introduction to benefits of a functional programming style.

Debugging Tips¶

This section collects tips on debugging RGP's C and R components.

Debugging RGP C Code¶

• Debugging Garbage Collector Problems
  • Call gctorture(TRUE) in R and R_gc() in C around possibly problematic code. This should help to identify to location of leaks, as errors will occur close to the problematic source code line.
  • Follow this rule on memory management given in the R documentation: "It is safe to modify the value of any SEXP foo for which NAMED(foo) is
    zero, and if NAMED(foo) is two, the value should be duplicated (via a
    call to duplicate()) before any modification. Note that it is the
    responsibility of the author of the code making the modification to do
    the duplication, even if it is x whose value is being modified after y
<- x."

Debugging RGP R Code¶

Coding Style¶

• New R source code should follow Hadley Wickham's style guide: https://github.com/hadley/devtools/wiki/Style
• New C source code should follow K&R style ("one true brace style").

(back to the RGP Documentation Workshop)