This is the repository for the R programming guideline of the Food and Agricultural Organization of the United Nations.
-
Have meaningful names for your
varable,function, andscript -
Keep the functions simple and compact. Do one thing and do it well. (rule of thumb, do not exceed 100 lines).
-
Wrap your code, do not exeed 80~100 characters, indent your code both 2 or 4 space are fine. Using an editor such as R Studio will help you with this.
-
Comment your code, they act like pseudo codes. See example at
functions/imputationExample.Randanalysis/analysis.R.
Unlike other languages, there is no one single style for programming in R. Listed below are several sources of coding style, the style you choose does not really matter, just be consistent.
Documentation is a daunting yet necessary task, thankfully these are
made simple with the R package roxygen2.
A simple use of the roxygen declaration can be found in the
hello_world.R and imputationExample.R under the functions
folder.
Roxygen: Simple documentation for R
In order for other users to quickly understand and debug your code if necessary, comment are necessary.
A simple description such as Perform data manipulation or Performing linear regression for prediction should suffice.
The purpose is to tell the user what task is performed at each step. This allows people to skim through the script to understand the purpose and the logic of the analysis and program.
Organization of project is another crucial element in helping people understanding your work.
Each function should be in a seperate script, the function should be compact and efficient and contained within a single folder.
A function should do only one thing, and do it well - Curly's Law
It is generally better to split up the function, each with their own documentation and do just one thing. You can then have a wrapper function to wrap everything up if you would like.
Functions should also have simple statements at the beginning of their execution that ensure that passed values are valid. For example, if a function takes three arguments a, b, and c and adds them together, then the function should ensure a, b, and c are all numeric before proceeding. These checks can easily be implemented via the stopifnot R function which returns an error if the argument is not true. Custom error messages can be implemented via: if(condition) stop("").
Tests should also be implemented to verify that functions work as expected. A "tests" directory should be created in the same directory as the package directory, and test files should be placed in the tests directory. These files should be named "test_..." and contain simple examples of use cases for these functions. The testthat package can be used to easily automate these tests. The stringr package has many good examples of what these test files should look like.
This repository illustrates how I usually organize my work which may be very restrictive. However the important point to note is that there is a logical structure.
Reshaping Data with the reshape Package After the publication of this paper the author created new version of reshape - 'reshape2', where cast was changed to dcast/acast.
The Split-Apply-Combine Strategy for Data Analysis
stringr: modern, consistent string processing