====== Guideline ======
===== SVN =====

Please comply with these:
  - Always write a commit-message (no exception). Write the whole commit-message in exactly **1 line (no linebreaks)** and separate - if appropriate - single items with semi-colon ';'.
  - Try to separate independent changes into several commits. Each coherent change one commit (there might be exceptions)
==== How to commit? ====
  * Check your modifications.
<code>
$ svn diff       # comfortable: svn diff | view -
$ svn status
</code>

  * Check if there are new revisions of files. Detect/prevent conflicts. (See the [[http://svnbook.red-bean.com/nightly/en/svn.tour.cycle.html#svn.tour.cycle.resolve|SVN Manual]] about resolving conflicts)
<code>
$ svn status -u
$ svn update
</code>

  * If everything seems to be fine, commit.
<code>
$ svn commit -m'commit message' [<files>]
</code>

===== trac =====

==== Creating a new ticket ====

  * Summary: short description of the problem/bug/enhancement/task
  * //Reporter: in most cases this is YOU//
  * Description: detailed description. If the ticket describes a bug, try to add a section "Steps to reproduce" and always write on which revision the bug occurs.
  * Type: Is it a bug, an enhancement or a task?
  * //Priority: most cases this should be left on the default value//
  * Milestone: till when should the ticket be fixed? If it's not release/milestone related, leave this field blank. If it's not scheduled for a specific release/milestone, set milestone "Future".
  * Component: select the appropriate component. If nothing fits, select "other".
  * Version: in which released version does the problem occur? If the problem occurs in current development tree, select "trunk".
  * //Keywords: optionally, needs not to be filled//
  * //CC: not needed (yet)//
  * Assign to: if you know that someone (including you) is currently working on this ticket or is going to work on this ticket, type in the developers name.

==== Closing tickets ====

  * set the appropriate solution
  * add a short description to field "comment". If appropriate, add a reference to the changeset (with r123 or changeset:123).

===== About the code =====

Please comply with these:
  - Try to be generous and verbose with comments.
  - Coding style:
    * Use tabs for indention instead of spaces (**tab-width = 8 spaces**).
    * Curly brackets belong on their own line for statements. (valid for C++; for C-code put curly bracket in same line)
    * No spaces between round brackets and arguments. Arguments are separated by a space behind the comma.
    * Space between statement (e.g. if, while) and the following round bracket, but no space behind a function.
    * Pointer sign belongs to variable name (avoids things like this: ''int* a, b'' which in fact means ''int *a, b'').
  - For new source/header files use the docs/license_stub.txt header as template
  - **Important:** Always save with UNIX line-endings (**NOT** MS-DOS line-endings)

Example code:
<code=c++>
if (true)
{
	do_something();    // do something useful
}
else
	do_something(123, arg2, etc);


int *x, *y;


float* calc(float a, float b)
{
	return a + b;
}

class ExampleClass
{
public:
	ExampleClass();
	void setValue(int value);
	int getValue() const { return value; };

private:
	int value;
	int flags;
};

void ExampleClass::setValue(int value)
{
	// this-pointer needed if same variable name in current scope
	this->value = value;

	// no this-pointer for members
	flags = 0x123;
}


switch (option)
{
case value1:
	something();
	break;

case value2:
	something();
	break;

default:
	something_other();
}

</code>