Home

Welcome to the Software Development Wiki!

The idea of this wiki is to document whatever Software Development practices should we consider as standards. To contribute, please attain to the follow guidelines:

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

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

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

1. Coding Standards: Anything that has to do with coding itself so that it's more readable, this includes naming variables, functions, and classes, code indenting, etc.

2. Software Thinking: Before starting to write a piece of software...

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

4. Misc

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`

# <a name="software-thinking"></a> Software Thinking




# <a name="development-workflow"></a> 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:
    
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)

# <a name="misc"></a>Misc

## R-packages

*   [`devtools`](https://github.com/hadley/devtools#devtools): An R package for package developers.
*   [`roxygen`](https://github.com/klutometis/roxygen#roxygen2): For documenting functions.
*   [`testthat`](https://github.com/hadley/testthat#testthat): For making testing fun.
*   [`codecov`](https://github.com/jimhester/covr#covr): To track the code coverage.

## More references

* _The Art of R programming_
* _R packages_