Guideline

Please comply with these:

1. 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 ';'.
2. Try to separate independent changes into several commits. Each coherent change one commit (there might be exceptions)

• Check your modifications.

$ svn diff       # comfortable: svn diff | view -
$ svn status

• Check if there are new revisions of files. Detect/prevent conflicts. (See the SVN Manual about resolving conflicts)

$ svn status -u
$ svn update

• If everything seems to be fine, commit.

$ svn commit -m'commit message' [<files>]

• 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.

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

Please comply with these:

1. Try to be generous and verbose with comments.
2. 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).
3. For new source/header files use the docs/license_stub.txt header as template
4. Important: Always save with UNIX line-endings (NOT MS-DOS line-endings)

Example code:

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();
}