mirror of
https://git.kernel.org/pub/scm/bluetooth/bluez.git
synced 2024-11-16 00:34:39 +08:00
01ddd8da3e
The documentation contained minor typos which are being fixed here.
280 lines
6.3 KiB
Plaintext
280 lines
6.3 KiB
Plaintext
BlueZ coding style
|
|
******************
|
|
|
|
Every project has its coding style, and BlueZ is not an exception. This
|
|
document describes the preferred coding style for BlueZ code, in order to keep
|
|
some level of consistency among developers so that code can be easily
|
|
understood and maintained.
|
|
|
|
First of all, BlueZ coding style must follow every rule for Linux kernel
|
|
(http://www.kernel.org/doc/Documentation/CodingStyle). There also exists a tool
|
|
named checkpatch.pl to help you check the compliance with it. Just type
|
|
"checkpatch.pl --no-tree patch_name" to check your patch. In theory, you need
|
|
to clean up all the warnings and errors except this one: "ERROR: Missing
|
|
Signed-off-by: line(s)". BlueZ does not used Signed-Off lines, so including
|
|
them is actually an error. In certain circumstances one can ignore the 80
|
|
character per line limit. This is generally only allowed if the alternative
|
|
would make the code even less readable.
|
|
|
|
Besides the kernel coding style above, BlueZ has special flavors for its own.
|
|
Some of them are mandatory (marked as 'M'), while some others are optional
|
|
(marked as 'O'), but generally preferred.
|
|
|
|
M1: Blank line before and after an if/while/do/for statement
|
|
============================================================
|
|
|
|
There should be a blank line before if statement unless the if is nested and
|
|
not preceded by an expression or variable declaration.
|
|
|
|
Example:
|
|
1)
|
|
a = 1;
|
|
if (b) { // wrong
|
|
|
|
2)
|
|
a = 1
|
|
|
|
if (b) {
|
|
}
|
|
a = 2; // wrong
|
|
|
|
3)
|
|
if (a) {
|
|
if (b) // correct
|
|
|
|
4)
|
|
b = 2;
|
|
|
|
if (a) { // correct
|
|
|
|
}
|
|
|
|
b = 3;
|
|
|
|
The only exception to this rule applies when a variable is being checked for
|
|
errors as such:
|
|
|
|
err = stat(filename, &st);
|
|
if (err || !S_ISDIR(st.st_mode))
|
|
return;
|
|
|
|
M2: Multiple line comment
|
|
=========================
|
|
|
|
If your comment has more than one line, please start it from the second line.
|
|
|
|
Example:
|
|
/*
|
|
* first line comment // correct
|
|
* ...
|
|
* last line comment
|
|
*/
|
|
|
|
|
|
M3: Space before and after operator
|
|
===================================
|
|
|
|
There should be a space before and after each operator.
|
|
|
|
Example:
|
|
a + b; // correct
|
|
|
|
|
|
M4: Wrap long lines
|
|
===================
|
|
|
|
If your condition in if, while, for statement or a function declaration is too
|
|
long to fit in one line, the new line needs to be indented not aligned with the
|
|
body.
|
|
|
|
Example:
|
|
1)
|
|
if ((adapter->supported_settings & MGMT_SETTING_SSP) &&
|
|
!(adapter->current_settings & MGMT_SETTING_SSP)) // wrong
|
|
|
|
2)
|
|
if ((adapter->supported_settings & MGMT_SETTING_SSP) &&
|
|
!(adapter->current_settings & MGMT_SETTING_SSP))
|
|
|
|
3)
|
|
void btd_adapter_register_pin_cb(struct btd_adapter *adapter,
|
|
btd_adapter_pin_cb_t cb) // wrong
|
|
|
|
4)
|
|
void btd_adapter_register_pin_cb(struct btd_adapter *adapter,
|
|
btd_adapter_pin_cb_t cb)
|
|
|
|
The referred style for line wrapping is to indent as far as possible to the
|
|
right without hitting the 80 columns limit.
|
|
|
|
M5: Space when doing type casting
|
|
=================================
|
|
|
|
There should be a space between new type and variable.
|
|
|
|
Example:
|
|
1)
|
|
a = (int *)b; // wrong
|
|
2)
|
|
a = (int *) b; // correct
|
|
|
|
|
|
M6: Don't initialize variable unnecessarily
|
|
===========================================
|
|
|
|
When declaring a variable, try not to initialize it unless necessary.
|
|
|
|
Example:
|
|
int i = 1; // wrong
|
|
|
|
for (i = 0; i < 3; i++) {
|
|
}
|
|
|
|
M7: Follow the order of include header elements
|
|
===============================================
|
|
|
|
When writing an include header the various elements should be in the following
|
|
order:
|
|
- #includes
|
|
- forward declarations
|
|
- #defines
|
|
- enums
|
|
- typedefs
|
|
- function declarations and inline function definitions
|
|
|
|
M8: Internal headers must not use include guards
|
|
================================================
|
|
|
|
Any time when creating a new header file with non-public API, that header
|
|
must not contain include guards.
|
|
|
|
M9: Naming of enums
|
|
===================
|
|
|
|
Enums must have a descriptive name. The enum type should be small caps and
|
|
it should not be typedef-ed. Enum contents should be in CAPITAL letters and
|
|
prefixed by the enum type name.
|
|
|
|
Example:
|
|
|
|
enum animal_type {
|
|
ANIMAL_TYPE_FOUR_LEGS,
|
|
ANIMAL_TYPE_EIGHT_LEGS,
|
|
ANIMAL_TYPE_TWO_LEGS,
|
|
};
|
|
|
|
If the enum contents have values (e.g. from specification) the formatting
|
|
should be as follows:
|
|
|
|
enum animal_type {
|
|
ANIMAL_TYPE_FOUR_LEGS = 4,
|
|
ANIMAL_TYPE_EIGHT_LEGS = 8,
|
|
ANIMAL_TYPE_TWO_LEGS = 2,
|
|
};
|
|
|
|
M10: Enum as switch variable
|
|
============================
|
|
|
|
If the variable of a switch is an enum, you must include all values in
|
|
switch body even if providing default. This is enforced by compiler option
|
|
enabling extra warning in such case. The reason for this is to ensure that if
|
|
later on enum is modified and one forget to change the switch accordingly, the
|
|
compiler will complain the new added type hasn't been handled.
|
|
|
|
Example:
|
|
|
|
enum animal_type {
|
|
ANIMAL_TYPE_FOUR_LEGS = 4,
|
|
ANIMAL_TYPE_EIGHT_LEGS = 8,
|
|
ANIMAL_TYPE_TWO_LEGS = 2,
|
|
};
|
|
|
|
enum animal_type t;
|
|
|
|
switch (t) { // OK
|
|
case ANIMAL_TYPE_FOUR_LEGS:
|
|
...
|
|
break;
|
|
case ANIMAL_TYPE_EIGHT_LEGS:
|
|
...
|
|
break;
|
|
case ANIMAL_TYPE_TWO_LEGS:
|
|
...
|
|
break;
|
|
default:
|
|
break;
|
|
}
|
|
|
|
switch (t) { // Wrong
|
|
case ANIMAL_TYPE_FOUR_LEGS:
|
|
...
|
|
break;
|
|
case ANIMAL_TYPE_TWO_LEGS:
|
|
...
|
|
break;
|
|
default:
|
|
break;
|
|
}
|
|
|
|
However if the enum comes from an external header file outside BlueZ, such as
|
|
Android headers, we cannot make any assumption of how the enum is defined and
|
|
this rule might not apply.
|
|
|
|
M11: Always use parenthesis with sizeof
|
|
=======================================
|
|
|
|
The expression argument to the sizeof operator should always be in
|
|
parenthesis, too.
|
|
|
|
Example:
|
|
1)
|
|
memset(stuff, 0, sizeof(*stuff));
|
|
|
|
2)
|
|
memset(stuff, 0, sizeof *stuff); // Wrong
|
|
|
|
M12: Use void if function has no parameters
|
|
===========================================
|
|
|
|
A function with no parameters must use void in the parameter list.
|
|
|
|
Example:
|
|
1)
|
|
void foo(void)
|
|
{
|
|
}
|
|
|
|
2)
|
|
void foo() // Wrong
|
|
{
|
|
}
|
|
|
|
O1: Try to avoid complex if body
|
|
================================
|
|
|
|
It's better not to have a complicated statement for if. You may judge its
|
|
contrary condition and return | break | continue | goto ASAP.
|
|
|
|
Example:
|
|
1)
|
|
if (device) { // worse
|
|
memset(&eir_data, 0, sizeof(eir_data));
|
|
if (eir_len > 0)
|
|
eir_parse(&eir_data, ev->eir, eir_len);
|
|
...
|
|
} else {
|
|
error("Unable to get device object for %s", addr);
|
|
return;
|
|
}
|
|
|
|
2)
|
|
if (!device) {
|
|
error("Unable to get device object for %s", addr);
|
|
return;
|
|
}
|
|
|
|
memset(&eir_data, 0, sizeof(eir_data));
|
|
if (eir_len > 0)
|
|
eir_parse(&eir_data, ev->eir, eir_len);
|
|
...
|