[lttng-tools.git] / CodingStyle

LTTng-Tools Coding Style

Last Update: 23/07/2012

C Style:
-------------

The coding style used for this project follows the the Linux kernel guide
lines, except that brackets "{", "}" should typically be used even for
single-line if/else statements. Please refer to:

- doc/kernel-CodingStyle.txt (copied from Linux 3.4.4 git tree).

- Linux kernel scripts/checkpatch.pl for a script which verify the patch
  coding style.

Error handling:
-------------

We ask to use one single return point in a function. For that, we uses the
"goto" statement for the error handling creating one single point for error
handling and return code. See the following example:

int some_function(...)
{
	int ret;
	[...]

	if (ret != 0) {
		goto error;
	}

	[...]
error:
	return ret;
}

Commenting:
-------------

Every function MUST have a comment above it even if the function is trivial.

Please add non-trivial comments/documentation as much as you can in the code.
Poor comments WILL be rejected upon merging so please pay attention to this
details because we do!
Commit	Line	Data
	1	LTTng-Tools Coding Style
	2
	3	Last Update: 23/07/2012
	4
	5	C Style:
	6	-------------
	7
	8	The coding style used for this project follows the the Linux kernel guide
	9	lines, except that brackets "{", "}" should typically be used even for
	10	single-line if/else statements. Please refer to:
	11
	12	- doc/kernel-CodingStyle.txt (copied from Linux 3.4.4 git tree).
	13
	14	- Linux kernel scripts/checkpatch.pl for a script which verify the patch
	15	coding style.
	16
	17	Error handling:
	18	-------------
	19
	20	We ask to use one single return point in a function. For that, we uses the
	21	"goto" statement for the error handling creating one single point for error
	22	handling and return code. See the following example:
	23
	24	int some_function(...)
	25	{
	26	int ret;
	27	[...]
	28
	29	if (ret != 0) {
	30	goto error;
	31	}
	32
	33	[...]
	34	error:
	35	return ret;
	36	}
	37
	38	Commenting:
	39	-------------
	40
	41	Every function MUST have a comment above it even if the function is trivial.
	42
	43	Please add non-trivial comments/documentation as much as you can in the code.
	44	Poor comments WILL be rejected upon merging so please pay attention to this
	45	details because we do!