Home

Welcome to the Software Development Wiki!

The idea of this wiki is to document the Software Development practices that we consider as standards. To contribute, please respect the following guidelines:

1. Keep it simple: The home page (this page) is for general guidelines. More elaborate recommendations or examples should be provided in the specific page for each topic.

2. Unless previously agreed, don't overwrite content.

And that's it! Currently, the wiki is divided into the following sections:

1. Coding Standards: Anything that has to do with coding itself, aimed at making it more readable. This includes naming variables, functions, and classes, code indenting, etc.

2. Software Thinking: Things to consider before starting to write a piece of software...

3. Development Workflow: For now, mostly focused on R, general guidelines for developing Statistical Software.

4. Misc

We also have a section about our Bioghost server, which hosts information regarding how to install and setup Unix software here.

Coding Standards

General Overview

1. The 80 characters rule.
2. When possible, structure your code as sections/files, with files holding similar functions and sections to give internal structure to your file.
3. Use white space for indenting, 4 characters.
4. Explain yourself: Add comments.

Control-flow statements

1. Single line if

   # If it's only a single like
   if (...)
       ...then...

2. Multiple lines ifelse

   # Several blocks
   if (...) {
       ...then...
   } else {
       ...
   }

Variable/Objects names

1. Never use dots to name objects, e.g. my.object. Both R and C++ use the dot symbol to access (or call) methods. Instead use either underscore or capital letters, e.g. my_object or myObject.
2. Whenever possible, use informative names, e.g. loglike instead of var1

Software Thinking

Development Workflow

General Overview

Unfolding the "Software Thinking", once you have set up the project (whereas an R package, C/C++ library, etc.), the development workflow is an iterative process. For each fun in functions do the following:

1. Write down the function.
2. Document the function: Input/output, examples, and references.
3. Write down the tests.
4. Build (compile) the package.
5. Run the tests and make sure fun didn't break anything.
6. Update the news.md and ChangeLog files (that sounds like a good idea).

Misc

R-packages

For R package development

• devtools: An R package for package developers.
• roxygen: For documenting functions.
• testthat: For making testing fun.
• codecov: To track the code coverage.

For reproducible research

• ProjectTemplate A complete workflow for reproducible research.
• represtools An alternative to ProjectTemplate.
• CodeDepends Analyzes your code to see dependencies.
• reproducible An alternative to ProjectTemplate.

More references

• R packages
• Advanced R
• R Graphics Cookbook
• The Art of R Programming