devel:guideline

Guideline

SVN

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)

How to commit?

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

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:

  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();
}
 
 
Recent changes RSS feed Creative Commons License Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki Get HoldingNuts at SourceForge.net. Fast, secure and Free Open Source software downloads