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
• Indentation depth of four spaces is also okay, we're not religious about that. As long as it's spaces and not tabs.
• 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 suffix for files is .r, not .R.
• 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

Basic rules

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

• 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

• Inconsistent use of spaces and tabs
• CamelCase for function names
• Stray space around parentheses

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.