1 | .. SPDX-License-Identifier: CC-BY-SA-4.0 |
---|
2 | |
---|
3 | .. Copyright (C) 2018. |
---|
4 | .. COMMENT: RTEMS Foundation, The RTEMS Documentation Project |
---|
5 | |
---|
6 | .. COMMENT:TBD - Convert the following to Rest and insert into this file |
---|
7 | .. COMMENT:TBD - https://devel.rtems.org/wiki/Developer/Coding/Conventions |
---|
8 | |
---|
9 | Coding Conventions |
---|
10 | ****************** |
---|
11 | |
---|
12 | The style of RTEMS is generally consistent in the core areas. This section |
---|
13 | attempts to capture generally accepted practices. When in doubt, consult the |
---|
14 | code around you, look in the RTEMS sources in the directories |
---|
15 | :file:`cpukit/include/rtems/score` and :file:`cpukit/score`, or ask on the |
---|
16 | :r:list:`devel`. |
---|
17 | |
---|
18 | Source Documentation |
---|
19 | -------------------- |
---|
20 | |
---|
21 | * Use Doxygen according to our :ref:`DoxygenGuidelines`. |
---|
22 | |
---|
23 | * Use the file templates, see :ref:`FileTemplates`. |
---|
24 | |
---|
25 | * Use ``/* */`` comments. |
---|
26 | |
---|
27 | * Do not use ``//`` comments. |
---|
28 | |
---|
29 | * Use comments wisely within function bodies, to explain or draw attention |
---|
30 | without being verbose. |
---|
31 | |
---|
32 | * Use English prose and strive for good grammar, spelling, and punctuation. |
---|
33 | |
---|
34 | * Use ``TODO`` with a comment to indicate code that needs improvement. Make |
---|
35 | it clear what there is to do. Add a ticket and add a link to it. |
---|
36 | |
---|
37 | * Use ``XXX`` or ``FIXME`` to indicate an error/bug/broken code. Add a ticket |
---|
38 | and add a link to it. |
---|
39 | |
---|
40 | Licenses |
---|
41 | -------- |
---|
42 | |
---|
43 | The RTEMS Project has strict requirements on the types of software licenses |
---|
44 | that apply to software it includes and distributes. Submissions will be |
---|
45 | summarily rejected that do not follow the correct license or file header |
---|
46 | requirements. |
---|
47 | |
---|
48 | * Refer to :ref:`LicensingRequirements` for a discussion of the acceptable |
---|
49 | licenses and the rationale. |
---|
50 | |
---|
51 | * Refer to :ref:`FileHeaderCopyright` for example copyright/license comment |
---|
52 | blocks for various languages. |
---|
53 | |
---|
54 | Language and Compiler |
---|
55 | --------------------- |
---|
56 | |
---|
57 | * Use C99. |
---|
58 | |
---|
59 | * Treat warnings as errors: eliminate them. |
---|
60 | |
---|
61 | * Favor C, but when assembly language is required use inline |
---|
62 | assembly if possible. |
---|
63 | |
---|
64 | * Do not use compiler extensions. |
---|
65 | |
---|
66 | * Use the RTEMS macros defined in <rtems/score/basedefs.h> for abstracting |
---|
67 | compiler-specific features. For using attributes see the |
---|
68 | `GCC attribute syntax <https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html#Attribute-Syntax>`_. |
---|
69 | Prefer to place attributes in front of the declarator. Try to be in line |
---|
70 | with |
---|
71 | `C++11 attributes <https://en.cppreference.com/w/cpp/language/attributes>`_ |
---|
72 | and C11 keywords such as |
---|
73 | `_Noreturn <https://en.cppreference.com/w/c/language/_Noreturn>`_. |
---|
74 | |
---|
75 | * Use NULL for the null pointer, and prefer to use explicit |
---|
76 | checks against NULL, e.g., |
---|
77 | |
---|
78 | .. code-block:: c |
---|
79 | |
---|
80 | if ( ptr != NULL ) |
---|
81 | |
---|
82 | instead of |
---|
83 | |
---|
84 | .. code-block:: c |
---|
85 | |
---|
86 | if ( !ptr ) |
---|
87 | |
---|
88 | * Use explicit checks for bits in variables. |
---|
89 | |
---|
90 | * Example 1: Use |
---|
91 | |
---|
92 | .. code-block:: c |
---|
93 | |
---|
94 | if ( XBITS == (var & XBITS) ) |
---|
95 | |
---|
96 | to check for a set of defined bits. |
---|
97 | |
---|
98 | * Example 2: Use |
---|
99 | |
---|
100 | .. code-block:: c |
---|
101 | |
---|
102 | if ( (var & X_FLAGS) != 0) ) |
---|
103 | |
---|
104 | instead of |
---|
105 | |
---|
106 | .. code-block:: c |
---|
107 | |
---|
108 | if ( !!(var & X_FLAGS) ) |
---|
109 | |
---|
110 | to check for at least 1 defined bit in a set. |
---|
111 | |
---|
112 | * Use ``(void) unused;`` to mark unused parameters and set-but-unused |
---|
113 | variables immediately after being set. |
---|
114 | |
---|
115 | * Do not put function prototypes in C source files, any global functions |
---|
116 | should have a prototype in a header file and any private function |
---|
117 | should be declared static. |
---|
118 | |
---|
119 | * Declare global variables in exactly one header file. |
---|
120 | Define global variables in at most one source file. |
---|
121 | Include the header file declaring the global variable as |
---|
122 | the first include file if possible to make sure that the |
---|
123 | compiler checks the declaration and definition and that |
---|
124 | the header file is self-contained. |
---|
125 | |
---|
126 | * Do not cast arguments to any printf() or printk() variant. |
---|
127 | Use <inttypes.h> PRI constants for the types supported there. |
---|
128 | Use <rtems/inttypes.h> for the other POSIX and RTEMS types that |
---|
129 | have PRI constants defined there. This increases the portability |
---|
130 | of the printf() format. |
---|
131 | |
---|
132 | * Do not use the register keyword. It is deprecated since C++14. |
---|
133 | |
---|
134 | Readability |
---|
135 | ------------ |
---|
136 | |
---|
137 | * Understand and follow the `naming rules <https://devel.rtems.org/wiki/Developer/Coding/NamingRules>`_.. |
---|
138 | * Use typedef to remove 'struct', but do not use typedef |
---|
139 | to hide pointers or arrays. |
---|
140 | * Exception: typedef can be used to simplify function pointer types. |
---|
141 | |
---|
142 | * Do not mix variable declarations and code. |
---|
143 | * Declare variables at the start of a block. |
---|
144 | * Only use primitive initialization of variables at their declarations. |
---|
145 | Avoid complex initializations or function calls in variable declarations. |
---|
146 | * Do not put unrelated functions or data in a single file. |
---|
147 | * Do not declare functions inside functions. |
---|
148 | * Avoid deep nesting by using early exits e.g. return, break, continue. |
---|
149 | * Parameter checking should be done first with early error returns. |
---|
150 | * Avoid allocation and critical sections until error checking is done. |
---|
151 | * For error checks that require locking, do the checks early after acquiring locks. |
---|
152 | * Use of 'goto' requires good reason and justification. |
---|
153 | |
---|
154 | * Test and action should stay close together. |
---|
155 | * Avoid complex logic in conditional and loop statements. |
---|
156 | * Put conditional and loop statements on the line after the expression. |
---|
157 | * Favor inline functions to hide |
---|
158 | `compile-time feature-conditioned compilation <https://devel.rtems.org/wiki/Developer/Coding/Compile-time_feature-conditioned_compilation>`_.. |
---|
159 | * Define non-inline functions in a .c source file. |
---|
160 | * Declare all global (non-static) functions in a .h header file. |
---|
161 | * Declare and define inline functions in one place. Usually, this |
---|
162 | is a *impl.h header file. |
---|
163 | * Declare and define static functions in one place. Usually, this is |
---|
164 | toward the start of a .c file. Minimize forward declarations of |
---|
165 | static functions. |
---|
166 | * Function declarations should include variable names. |
---|
167 | * Avoid excess parentheses. Learn the |
---|
168 | `operator precedence <https://en.wikipedia.org/wiki/Operators_in_C_and_C%2B%2B#Operator_precedence>`_. rules. |
---|
169 | * Always use parentheses with sizeof. This is an exception to the rule |
---|
170 | about excess parentheses. |
---|
171 | |
---|
172 | Robustness |
---|
173 | ----------- |
---|
174 | |
---|
175 | * Check all return statuses. |
---|
176 | * Validate input parameters. |
---|
177 | * Use debug assertions (assert). |
---|
178 | * Use const when appropriate for read-only function parameters |
---|
179 | and compile-time constant values. |
---|
180 | * Do not hard code limits such as maximum instances into your code. |
---|
181 | * Prefer to use sizeof(variable) instead of sizeof(type). |
---|
182 | * Favor C automatic variables over global or static variables. |
---|
183 | * Use global variables only when necessary and ensure |
---|
184 | atomicity of operations. |
---|
185 | * Do not shadow variables. |
---|
186 | * Avoid declaring large buffers or structures on the stack. |
---|
187 | * Avoid using zero (0) as a valid value. Memory often |
---|
188 | defaults to being zero. |
---|
189 | * Favor mutual exclusion primitives over disabling preemption. |
---|
190 | * Avoid unnecessary dependencies, such as by not calling |
---|
191 | ''printf()'' on error paths. |
---|
192 | * Avoid inline functions and macros with complicated logic |
---|
193 | and decision points. |
---|
194 | * Prefer inline functions, enum, and const variables instead of CPP macros. |
---|
195 | * CPP macros should use a leading underscore for parameter |
---|
196 | names and `avoid macro pitfalls <https://gcc.gnu.org/onlinedocs/cpp/Macro-Pitfalls.html#Macro-Pitfalls>`_.. |
---|
197 | |
---|
198 | Portability |
---|
199 | ----------- |
---|
200 | |
---|
201 | * Think portable! RTEMS supports a lot of target hardware. |
---|
202 | * For integer primitives, prefer to use precise-width integer |
---|
203 | types from C99 stdint.h. |
---|
204 | * Write code that is 16-bit, 32-bit, and 64-bit friendly. |
---|
205 | |
---|
206 | Maintainability |
---|
207 | --------------- |
---|
208 | |
---|
209 | * Minimize modifications to `third-party code <https://devel.rtems.org/wiki/Developer/Coding/ThirdPartyCode>`_. |
---|
210 | * Keep it simple! Simple code is easier to debug and easier to read than clever code. |
---|
211 | * Share code with other architectures, CPUs, and BSPs where possible. |
---|
212 | * Do not duplicate standard OS or C Library routines. |
---|
213 | |
---|
214 | Performance |
---|
215 | ----------- |
---|
216 | |
---|
217 | * Prefer algorithms with the `lowest order of time and space <https://devel.rtems.org/wiki/FAQ/AlgorithmicComplexity>`_. |
---|
218 | for fast, deterministic execution times with small memory footprints. |
---|
219 | * Understand the constraints of `real-time programming <https://devel.rtems.org/wiki/TBR/Review/Real-Time_Resources>`_.. |
---|
220 | Limit execution times in interrupt contexts and critical sections, |
---|
221 | such as Interrupt and Timer Service Routines (TSRs). |
---|
222 | * Prefer to ++preincrement instead of postincrement++. |
---|
223 | * Avoid using floating point except where absolutely necessary. |
---|
224 | |
---|
225 | Miscellaneous |
---|
226 | ------------- |
---|
227 | |
---|
228 | * If you need to temporarily change the execution mode of a |
---|
229 | task/thread, restore it. |
---|
230 | * If adding code to ''cpukit'' be sure the filename is unique since |
---|
231 | all files under that directory get merged into a single library. |
---|
232 | |
---|
233 | Header Files |
---|
234 | ------------ |
---|
235 | |
---|
236 | * Do not add top-level header files. Place the header files in a directory, |
---|
237 | for example ``#include <rtems/*>``, ``#include <bsp/*>``, |
---|
238 | ``#include <dev/*>``, etc. |
---|
239 | |
---|
240 | * Use the extension :file:`.h` for C header files. |
---|
241 | |
---|
242 | * Use the extension :file:`.hpp` for C++ header files. |
---|
243 | |
---|
244 | * Use the file template for header files, see :ref:`CCXXHeaderFileTemplate`. |
---|
245 | |
---|
246 | * Use separate header files for the API and the implementation. |
---|
247 | |
---|
248 | * Use :file:`foobar.h` for the header file of the ``foobar`` module which |
---|
249 | defines API components. |
---|
250 | |
---|
251 | * Use :file:`foobardata.h` for the header file of the ``foobar`` module which |
---|
252 | defines interfaces used by the application configuration. |
---|
253 | |
---|
254 | * Use :file:`foobarimpl.h` for the header file of the ``foobar`` module which |
---|
255 | defines interfaces, macros, and inline functions used by the implementation. |
---|
256 | |
---|
257 | * Do not place inline functions which are only used in one implementation |
---|
258 | source file into the implementation header file. Add these inline functions |
---|
259 | directly to the corresponding source file. |
---|
260 | |
---|
261 | * Document all elements in header files with comments in Doxygen markup, see |
---|
262 | :ref:`DoxygenGuidelines`. |
---|
263 | |
---|
264 | * Only place header files which should be directly included by the user with an |
---|
265 | ``@file`` Doxygen directive into the API documentation group. Place internal |
---|
266 | API header files with an ``@file`` Doxygen command into the implementation |
---|
267 | documentation group even if they define API elements. The API documentation |
---|
268 | group should only list public header files and no internal header files. |
---|
269 | |
---|
270 | Layering |
---|
271 | -------- |
---|
272 | |
---|
273 | * TBD: add something about the dependencies and header file layering. |
---|
274 | * Understand the `RTEMS Software Architecture <https://devel.rtems.org/wiki/TBR/UserManual/RTEMS_Software_Architecture>'_. |
---|
275 | |
---|
276 | Exceptions to the Rules |
---|
277 | ----------------------- |
---|
278 | |
---|
279 | * Minimize reformatting existing code in RTEMS unless the file undergoes |
---|
280 | substantial non-style changes. |
---|
281 | * `Third-party code <https://devel.rtems.org/wiki/Developer/Coding/ThirdPartyCode>`_. |
---|
282 | should not be reformatted to fit RTEMS style. |
---|
283 | Exception: unmaintained third-party code adopted and |
---|
284 | maintained by RTEMS may be reformatted, subject to the |
---|
285 | above rules. |
---|
286 | |
---|
287 | Tools |
---|
288 | ----- |
---|
289 | |
---|
290 | Some of the above can be assisted by tool support. Feel free to add |
---|
291 | more tools, configurations, etc here. |
---|
292 | |
---|
293 | * `Uncrustify <http://uncrustify.sourceforge.net/>`_. |
---|
294 | Configuration for RTEMS: |
---|
295 | `rtems.uncrustify <https://devel.rtems.org/attachment/wiki/Developer/Coding/Conventions/rtems.uncrustify>`_. |
---|