ChiliProject is not maintained anymore. Please be advised that there will be no more updates.

We do not recommend that you setup new ChiliProject instances and we urge all existing users to migrate their data to a maintained system, e.g. Redmine. We will provide a migration script later. In the meantime, you can use the instructions by Christian Daehn.

« Previous - Version 5/13 (diff) - Next » - Current version
Andrew Smith, 2012-03-25 04:49 am

Code Standards


These are the standard on how code should be formatted and structured in ChiliProject. Always follow these standards when submitting any code.

We recognize that it could make sense to occasionally divert from one of the following rules. Always keep in mind that these rules are in place to allow everybody to quickly navigate every part the code. Thus readability should always be the highest goal when formatting your code.

Every code in ChiliProject including comments and variable names has to be written in English. Use the correct grammar and spelling everywhere.

Ruby on Rails

Generally follow the common Ruby and Rails standards. Especially on where to put things. See the following resources for general information about Ruby's coding style:

The rules stated in this document override rules stated in the above documents if there is a conflict.

Code formatting

Set your editor to use soft-tabs at two spaces for ruby code. Never use actual tab-characters as they will destroy the indentation for users with different tab settings.

Configure your editor to automatically remove trailing whitespace and be sure to leave an empty new-line at the end of file. Always use UNIX line-endings (0x0A, \n). Don't use windows line-endings (\r\n).

Try keep source code as readable as possible:
  • Use proper indentation.
  • Try to keep line length below 80 chars with a hard limit of 120 chars. Use line continuations for long lines where appropriate.
  • Insert an blank lines between method definitions and two blank lines between class definitions.
  • Skip parentheses in ruby where it makes sense, that is most calls to things, but never in the declaration of things (see below).

Never use double spaces anywhere else than for indentation.


  • Avoid the usage of the return keyword. Use it only where absolutely necessary or when it helps to describe the intention (e.g. a return that is deep inside of a nested method). Try to restructure your code first to have a clear flow without breaks.
  • Don't use and and or. Use && and || instead.
  • On defining methods always use parentheses around the argument specification. Leave no spaces there. Omit the parentheses when there are no arguments.
    1def foo ( a, b )
    2  # do something
    5def bar()
    6  "foobar" 
    1def foo(a, b)
    2  # do something
    5def bar
    6  "foobar" 

When naming variables, use self-describing names. Use abbreviations sparingly and only when its meaning is absolutely clear. There are people from about every culture in the world working on ChiliProject, so be clear.


Keep the hash keys tight with no whitespace before or after them. Use one space after each comma.

1# Good
2{:color => 'blue', :object => @issue}
4# Bad
5{ :color => 'blue', :object => @issue}
6{ :color => 'blue', :object => @issue }
7{:color => 'blue',:object => @issue}

Large hashes should be broken up so each key is on one line. This is also useful for hashes that are changed often, git can track a single key change easily since it's on a single line.

 1# Good
 2issue_attributes = {
 3  :subject => 'Code standards',
 4  :description => 'Bar'
 7# Good, passing a hash style
 9                   :subject => 'Code standards',
10                   :description => 'Bar'
11                 })
12# Bad
13issue_attributes = {
14:subject => 'Code standards',
15:description => 'Bar'
18issue_attributes = {
19  :subject => 'Code standards', :description => 'Bar'
22issue_attributes = {
23                    :subject => 'Code standards',
24                    :description => 'Bar'

Avoid trying to line up anything more than the start of the keys. They can look nice but cause the entire hash to be reformatted whenever a key grows. This makes tools like git blame more difficult to use and track what happened.

 1# Before
 2issue_attributes = {
 3  :subject     => 'Code standards',
 4  :description => 'Bar'
 7# After, notice how the change was to the first key but the second one also had to be changed to be reformatted.
 8issue_attributes = {
 9  :subject_was_extended => 'Code standards',
10  :description          => 'Bar'


Use comments to describe what your code is doing, but don't try to write the Great American Novel in a comment or state the obvious like the following comment does.

1def add(x, y)
2  # Add x and y
3  x + y

If you need to use more than a few lines of comments, consider refactoring the code into methods that are more descriptive.

If something is unfinished, add a comment prefixed with "TODO". This will let the rake method of rake notes:todo to find them.

If something needs to be optimized, add a comment prefixed with "OPTIMIZE". This will let the rake method of rake notes:optimize to find them.

 1# OPTIMIZE: needs to be speed up, seeing over 30 second delays
 2def foo(a, b)
 3  sleep(42)
 6def bar
 7  # TODO: hardcoded
 8  "foobar"