Coding Guidelines
Coding Style
Zephyr’s coding style is described in the Zephyr Coding Style Guidelines. We want to follow this style for new files being introduced.
If in doubt, you can always reformat a file by running clang-format -i <file>
- but please create a distinct commit when doing this, and don’t mix formatting changes with functional ones!
Zephyr Coding Guidelines
Zephyr’s coding guidelines are described in the Zephyr Coding Guidelines.
It is advised to follow the guidelines to the best of your ability, however, some rules are quite difficult to achieve compliance with.
Additional Guidelines
The following additional guidelines apply to this project:
struct and enum Definitions
struct
and enum
definitions shall be preferred in place of struct
typedefs.
Example - Non-compliant:
typedef struct {
uint32_t field;
} foo_t; /* non-compliant */
Example - Compliant:
struct foo {
uint32_t field;
}; /* compliant */
Example - Non-compliant:
typedef enum {
ENTRY
} my_enum_e; /* non-compliant */
Example - Compliant:
enum my_enum {
ENTRY
}; /* compliant */
Exception: Function Pointers
Function pointer typedefs are acceptable and preferred for readability and maintainability.
Example - Acceptable:
typedef int (*message_handler_t)(const union request *req, struct response *rsp);
typedef void (*callback_func_t)(void *data);
struct message_dispatcher {
message_handler_t handler;
callback_func_t callback;
};
Naming Conventions
Snake case shall be preferred over camel case for variable names, function names, and other identifiers.
Example - Non-compliant:
int myVariableName; /* non-compliant */
int calculateMaxValue(void); /* non-compliant */
struct myDataStruct { /* non-compliant */
int fieldValue; /* non-compliant */
};
Example - Compliant:
int my_variable_name; /* compliant */
int calculate_max_value(void); /* compliant */
struct my_data_struct { /* compliant */
int field_value; /* compliant */
};