Coding conventions

This wasn't a page yet but it was listed on the Wiki home page.

Some coding conventions that we've discussed:

Use google's R style guide

When writing code, we usually strive for a set of coding syntax rules laid out by the R user community at Google. Syntax in the coding world means the spelling and grammar of a programming language. The guide was designed to make code easier to read, share, and verify. In the Data Management Section, we recommended also saving files according to the Google Style Guide.

In some circumstances, we've found that following the Google Style Guide is not practical or beneficial. For example, for variables, variable.name is preferred in google style but variableName is "accepted". However, sometimes parsing code from different sources leads to problems with the period case style but not the camelback case style. Many people in the lab also use camelcase to separate variables/data objects from functions which we often name with a verb (like "get") then an underscore and then the object of interest (like "stats"): get_stats. Drake lab users should follow Google R Style guide on curly braces, file names, indentation and spacing, function definition and calls, function documentation, assignment, general layout, and comments.

Reviewing code

• Have someone else review your code
• Partner programming
• If making HTML content, test it on multiple browsers before dissemination

Profiling code:

Profiling code allows you to quantify the computational cost of different parts of your programs This may be important if you have very computationally intensive projects. [More information on profiling code?]