1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
|
--------------------------------------------------------------------------------
1. Tizen rules that should be (partially) followed
--------------------------------------------------------------------------------
Differences from Tizen rules are included as "Notes". For full description of
each rule - please refer to Tizen documentation.
[R01] [CMT_M_C89] Both comment styles are allowed : C89 "/* ... */" style & C99 "//" style
Note: Temporary comments may use C99 style (TODO, FIXME etc.)
[R02] [DEC_R_INL] inline keyword should sit between storage class and type.
[M01] [IDT_M_TAB] Use tabs. All tabs are 4 characters. Indentation use only tab (No space key).
Note: If necessary use 4-character tabs + alignment spaces
[M02] [IDT_M_SCH] Switch and case should be at the same indent.
[R03] [IDT_R_LBL] goto labels aren't indented, allow a single space however.
Note: No single space allowed
[M03] [SPC_M_KWD] Keywords have following space rules
-Put a space after (most) keywords (ex: if, switch, case, for, do, while).
-Exception: Do not put a space after function like keywords, such as sizeof, typeof, alignof, __attribute__. -
[M04] [SPC_M_OPR] Operators have following space rules
-Put a space around(on each side of) most binary and ternary operators
-Example: = + -< > * / % | & ^ <= >= == != ? :
-Do not put a space after unary operators
-Example: & * + -~ !
-Unary ++ and unary --are allowed no space on one side.
-Do not put a space after cast operator
-Do not put a space around the "." and "->" structure member operators.
[M05] [SPC_M_SEP] Seperators have following space rules
-Put a space after closing brace when it has anything on the line.
-Exception : comma after closing brace '},'
-Put a space after comma
-Do not put space inside parenthesis '(', ')'
-Do not put a space after the function name in function calls.
-Do not put space before open square bracket '['; and inside square bracket '[', ']'.
[M06] [BRC_M_FTN] functions have the opening brace at the beginning of the next line.
[M07] [BRC_M_SMT] Statement brace: Open brace last on the line. The closing brace is empty on a line of its own.
-Exception: Where the closing race is followed by a continuation of the same statement, else should follow close brace '}',
while should follow close brace '}'
[M08] [BRC_M_EUS] Open braces for enum, union and struct go on the same line.
[R04] [BRC_R_SST] Do not unnecessarily use braces where a single statement will do.
-Exception: if one branch of a conditional statement is a single statement, use braces in both branches.
[R05] [LNE_R_TWS] No trailing whitespaces at the ends of lines.
[R06] [LNE_R_EOF] Check for adding lines without a newline at end of file.
Note: File should end with '\n' (single newline at the end of file)
[R07] In source file, the sequence of the code organization : Copyright, File comments, Header files, Define constant and macros, Declare static (private) functions, Define exported (public) functions, Define static (private) functions, Define protected functions.
Note: Static (private) function code first, then functions used by other objects in library; API (public) functions at the end
******** Public API should use 'API' macro - other functions are not visible outside of library
[M09] Separate external public header(API) and internal header(declare protected functions that are not exported but use for many files)
[M10] External public headers include the Doxygen style for comment. ex) Variable, Function, Struct.
[M11] In function prototypes, include parameter names with their data types and return type.
[R08] Macros with multiple statements should be enclosed in a "do -while" block.
[R09] ''#' symbol for macro shall be located at the first column.
[R10] In macro definition, every expression and the arguments in the expressions shall be enclosed by '(' and ')' for each.
[R11] Don’t declare both a structure tag and variables or typedefs in the same declaration.
Note: Avoid use of typedefs for structures/enums unless it's needed (for handles in API etc.)
[R12] Each variable shall be declared in the new line.
Notes: except for counters (like i, j, k, etc.).
[M12] No mixed-case, Use underscores('_') to separate words in a name.
[R13] Names of macros defining constants and labels in enums are composed of capital letters, numbers and '_' character.
[R14] Name of functions are Verb + Noun to have a good representation of features.
Note: this is rule of thumb except for Public API. Public API has prefix (<library>_<module>_fcn).
--------------------------------------------------------------------------------
2. Extra rules that should be followed
--------------------------------------------------------------------------------
- Line length
- soft limit (can be broken if expression will be more readable) 80 chars,
- hard limit 100 characters (should not be broken)
- Typedefs should be used only where necessary (for example to make private implementations)
- Function arguments should either fit one line, or each parameter should be placed in separate line
--------------------------------------------------------------------------------
3. Tizen rules that should NOT be followed
--------------------------------------------------------------------------------
[R15] Local functions whose scope is limited to the current source file have "static" keyword and names started with "__".
Note: static functions should not include "prefix" but can have arbitrary names (see R14).
[R16] Names of protected(global) functions in internal header are started with '_' character.
Note: Functions shared between multiple objects can have arbitrary naming (see R14)
|
