Style Guide

Style Guide for R

Basic rules

Please follow google's style guide for R (see ​http://google-styleguide.googlecode.com/svn/trunk/google-r-style.html), except in the following cases:

• Function names are of the form do.something.stupid, not DoSomesthingStupid
• Constants are of the form A.SUPER.CONSTANT, not kASuperConstant
• Comments on the same line as source codes start with a single hash sign (#); comments on an own line start with two hash signs (##). Rationale: ​ftp://ftp.stat.math.ethz.ch/ESS/ESS_html-o/ess_7.html#SEC54
• General function comments (scope, parameters, return values) should be placed on top of the function, not inside it.
• The Queen's English (in her role as Queen of Great Britain, not of the oversee dominions) is preferred over new-world variants.

Common mistakes

• Using tabs instead of spaces
• Opening brace of a function immediately follows function parameter list, that is, test <- function(x,y){ should be test <- function(x,y) {
• Stray whitespace at the end of lines (please avoid this; it makes integration more difficult because albeit lines look identical in editors, they are not for diff and patch
• Surrounding function parameters with spaces. Instead of return ( value ), write return(value)
• Using loooooooooong lines with >>> 80 chars.

Style Guide for Python

Use the standard conventions outlined on python.org

Style guide for mysql

Please perform all changes to the data model with mysql-workbench >= 6. Previous versions lead to differences in the generated SQL script (codeface_datamodel.sql), which makes tracking changes hard.

To commit a change, please add both, the differences in the binary and the changes to the SQL script, to the commit. This way, we keep track of the actual content of the changes that are not visible in the binary model alone.