RGP Coding Tips¶
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.
- 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.
This section collects tips on debugging RGP's C and R components.
Debugging RGP C Code¶
- Debugging Garbage Collector Problems
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
zero, and if
NAMED(foo)is two, the value should be duplicated (via a
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
xwhose value is being modified after
Debugging RGP R Code¶
- 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)