No new software may be included in the NuttX source tree that does not have licensing information included in the file.
No new software may be included in the NuttX source tree that does not have a Apache 2.0 license or license (or, in the case of 3rd party file, a compatible license such as the BSD or MIT licenses).
If the file does not follow Apache 2.0 licensing, then the appropriate license information should be provided in the header rather than the Apache 2.0 licensing information and a NOTE should be included in the top-level <code>COPYING</code> file to indicate any variations from Apache 2.0 licensing.
All like components in a C source or header file are grouped together.
Definitions do not appear arbitrarily through the file, rather, like definitions are grouped together and preceded by a <i>block comment</i> identifying the grouping.
</p>
<p>
<b>Block Comments</b>.
Each grouping in the file is separated with a <i>block comment</i>.
A line that consists of the opening C comment (<code>/*</code>) followed by a series of asterisks extending to the length of the line (usually to column 78).
An asterisk preceives the name of the grouping in column 1.
</li>
<li>
A line that consists of the closing C comment (<code>*/</code>) at the end of the line (usually column 78) preceded by a series of asterisks extending to column 1.
</li>
</ul>
<p>
<b>Examples of Block Comments</b>.
See <ahref="#appndxa">Appendix A</a> for examples of block comments.
</p>
<p>
<b>Order of Groupings</b>.
The following groupings should appear in all C source files in the following order:
C header file must protect against multiple inclusion through the use of macros that "guard" against multiple definitions if the header file is included multiple times.
Each header file must contain the following pre-processor conditional logic near the beginning of the header file: Between the file header and the "Included Files" block comment.
Files should be formatted with the newline character (<code>\n</code>) as the line ending (Unix-style line endings) and specifically <i>not</i> the carriage return, newline sequence (<code>\r\n</code>) used with Windows-style line endings.
There should be no extra whitespace at the end of the line.
In addition, all text files should end in a single newline (<code>\n</code>). This avoids the <i>"No newline at end of file"</i> warning generated by certain tools.
</p>
<p>
<b>Line Width</b>.
Text should not extend past column 78 in the typical C source or header file.
Sometimes the nature of the content of a file may require that the lines exceed this limit.
This often occurs in header files with naturally long definitions.
If the line width must extend 78 lines, then some wider line width may be used in the file provided that it is used consistently.
</p>
<p>
<b>Line Wrapping</b>.
</p>
<center><tablewidth="100%"border=1>
<tr><tdbgcolor="white">
<p><fontcolor="red"><b>Incorrect</b></p>
<ul><pre>
struct some_long_struct_name_s
{
struct some_long_struct_name_s *flink; /* The forward link to the next instance of struct some_long_struct_name_s in a singly linked list */
int short_name1; /* Short comment 1 */
int short_name2; /* This is a very long comment describing subtle aspects of the short_name2 field */
If the comment is too long to fit on a single, it must be broken into a multi-line comment.
The comment must be begin on the first line of the multi-line comment with the opening comment delimiter (<code>/*</code>).
The following lines of the multi-line comment must be with an asterisk (<code>*</code>) aligned in the same column as the asterisk in the preceding line.
The closing comment delimiter must lie on a separate line with the asterisk (<code>*</code>) aligned in the same column as the asterisk in the preceding line.
</p>
<center><tablewidth="60%"border=1>
<tr><tdbgcolor="white">
<p><fontcolor="red"><b>Incorrect</b></p>
<ul><pre>
/*
This is the first line of a multi-line comment.
This is the second line of a multi-line comment.
This is the third line of a multi-line comment. */
/* This is the first line of another multi-line comment. */
/* This is the second line of another multi-line comment. */
/* This is the third line of another multi-line comment. */
</ul></pre></font>
</td></tr>
<tr><tdbgcolor="white">
<p><fontcolor="green"><b>Correct</b></p>
<ul><pre>
/* This is the first line of a multi-line comment.
* This is the second line of a multi-line comment.
Comments to the right of statements in C source files are discouraged.
If such comments are used, they should be (1) very short so that they do not exceed the line width (typically 78 characters), (2) fit on one line, and (3) be aligned so that the comment begins in the same comment on each line.
Comments to the right of a declaration with an enumeration or structure, on the other hand, are encouraged, provided that the comments are short and do not exceed the maximum line width (usually 78 characters).
<b>Note</b> that if the comment is continued on multiple lines, the comment alignment and multi-line comment rules still apply with one exception: The closing <code>*/</code> appears on the same line as the final text of the comment. This exception to the rule is enforced to keep the statements and definitions from becoming to spread out.
Block comments are only used to delimit groupings with the overall <ahref="#fileorganization">file organization</a> and should not be used unless the usage is consistent with delimiting logical groupings in the program.
</p>
<p>
<b>C Style Comments</b>.
C99/C11/C++ style comments (beginning wih <code>//</code>) should not be used with NuttX.
NuttX generally follows C89 and all code outside of architecture specific directories must be compatible with C89.
In general, the use of braces in the NuttX coding standard is similar to the use of braces in the <ahref="https://www.gnu.org/prep/standards/standards.pdf">GNU Coding standards</a> with a few subtle differences.
Within this document, an opening left brace followed by a sequence of statments, and ending with a closing right brace is refered to as a <i>compound statement</i>.
</li>
<li>
<b>Nested Compound Statements</b>.
In the case where there are nested compound statements that end with several consecutive right braces, each closing right brace must lie on a separate line and must be indented to match the corresponding opening brace.
</li>
<li>
<b>Final brace followed by a single blank line</b>.
The <i>final</i> right brace must be followed by a blank line as per standard rules.
In general, the indentation in the NuttX coding standard is similar to the indentation requirements of the <ahref="https://www.gnu.org/prep/standards/standards.pdf">GNU Coding standards</a> with a few subtle differences.
All C statements (and case selectors) lie on lines that are multiples of 4 spaces (beginning with an indentation of two): 2, 6, 10, ... (4*n + 2) (for indentation level n = 0, 1, ...)
C Pre-processor commands following any conditional computation are also indented following basically the indentation same rules, differing in that the <code>#</code> always remains in column 1.
When C pre-processor statements are indented, they should be should be indented by 2 spaces per level-of-indentation following the <code>#</code>.
C pre-processor statements should be indented when they are enclosed within C pre-processor conditional logic (<code>#if</code>..<code>#endif</code>). The level of indentation increases with each level of such nested conditional logic.
</p>
<p>
C pre-processor statements should always be indented in this way in the <code>Pre-processor Definitions</code><ahref="#cfilestructure">section</a> of each file.
C pre-processor statements may be indented in the <code>Public/Private Data</code> and <code>Public/Private Functions</code> sections of the file.
However, often the indentation of C pre-processor statements conflicts with the indentation of the C code and makes the code more difficult to read.
In such cases, indentation of C pre-processor statements should be ommitted in those sections (only).
Do not put a left parenthesis (<code>(</code>) immediately after any C keywords (<code>for</code>, <code>switch</code>, <code>while</code>, <code>do</code>, <code>return</code>, etc.).
Put a space before the left parenthesis in these cases.
</li>
<li>
<b>Otherwise, no space before left parentheses</b>.
Otherwise, there should be no space before the left parentheses
</li>
<li>
<b>No space betwen function name and argument list</b>.
There should be no space between a function name and an argument list.
</li>
<li>
<b>Never space before the right parentheses</b>.
There should never be space before a right parenthesis (<code>)</code>).
</li>
<li>
<b>No parentheses around returned values</b>.
Returned values should never be enclosed in parentheses unless the parentheses are required to force the correct order of operations in a computed return value.
</li>
</ul>
<center><tablewidth="60%"border=1>
<tr><tdbgcolor="white">
<p><fontcolor="red"><b>Incorrect</b></p>
<ul><pre>
int do_foobar ( void )
{
int ret = 0;
int i;
for( i = 0; ( ( i < 5 ) || ( ret < 10 ) ); i++ )
{
ret = foobar ( i );
}
return ( ret );
}
</ul></pre></font>
</td></tr>
<tr><tdbgcolor="white">
<p><fontcolor="green"><b>Correct</b></p>
<ul><pre>
int do_foobar(void)
{
int ret = 0;
int i;
for (i = 0; i < 5 || ret < 10; i++)
{
ret = foobar(i);
}
return ret;
}
</ul></pre></font>
</td></tr>
</table></center>
<p>
<b>NOTE:</b>
Many people do not trust their understanding of the precedence of operators and so use lots of parentheses in expressions to force the order of evaluation even though the parentheses may have no effect.
This will certainly avoid errors due to an unexpected order of evaluation, but can also make the code ugly and overly complex (as in the above example).
In general, NuttX does not use unnecessary parentheses to force order of operations.
There is no particular policy in this regard.
However, you are are advised to check your C Programming Language book if necessary and avoid unnecessary parenthesis when possible.
</p>
<tablewidth ="100%">
<trbgcolor="#e4e4e4">
<td>
<h1>2.0 <aname="datatypes">Data and Type Definitions</a></h1>
</td>
</tr>
</table>
<h2>2.1 <aname="onedatperline">One Definition/Declaration Per Line</a></h2>
<center><tablewidth="60%"border=1>
<tr><tdbgcolor="white">
<p><fontcolor="red"><b>Incorrect</b></p>
<ul><pre>
extern long time, money;
char **ach, *bch;
int i, j, k;
</ul></pre></font>
</td></tr>
<tr><tdbgcolor="white">
<p><fontcolor="green"><b>Correct</b></p>
<ul><pre>
extern long time;
extern long money;
FAR char **ach;
FAR char *bch;
int i;
int j;
int k;
</ul></pre></font>
</td></tr>
</table></center>
<p>
<b>NOTE</b>:
See the discussion of <ahref="#farnear">pointers</a> for information about the <code>FAR</code> qualifier used above.
Names should be terse, but generally descriptive of what the variable is for.
Try to say something with the variable name, but don't try to say too much.
For example, the variable name of <code>g_filelen</code> is preferable to something like <code>g_lengthoffile</code>.
</li>
<li>
<b>Global variable prefix</b>.
All global variables begin with the prefix <code>g_</code> to indicate the scope of variable.
</li>
<li>
<b>Module name prefix</b>
If a global variable belongs in a <i>module</i> with a name of, say <code>xyz</code>, then that module should be included as part of the prefix like: <code>g_xyz_</code>.
</li>
<li>
<b>Lowercase</b>,
Use all lower case letters.
</li>
<li>
<b>Minimal use of <code>'_'</code></b>.
Preferably there are no <code>'_'</code> separators within the name.
Long variable names might require some delimitation using <code>'_'</code>.
Long variable names, however, are discouraged.
</li>
<li>
<b>Use structures</b>.
If possible, wrap all global variables within a structure to minimize the liklihood of name collisions.
</li>
<li>
<b>Avoid global variables when possible</b>.
Use of global variables, in general, is discourage unless there is no other reasonable solution.
<h2>2.3 <aname="localvariable">Parameters and Local Variables</a></h2>
<p><b>Coding Standard:</b></p>
<ul>
<li>
<b>Common naming standard</b>.
Naming for function parameters and local variables is the same.
</li>
<li>
<b>Short variable names</b>.
Names should be terse, but generally descriptive of what the variable is for.
Try to say something with the variable name, but don't try to say too much.
For example, the variable name of <code>len</code> is preferable to something like <code>lengthofiobuffer</code>.
</li>
<li>
<b>No special ornamentation</b>.
There is no special ornamentation of the name to indication that the variable is a local variable.
The prefix <code>p</code> or <code>pp</code> may be used on names of pointers (or pointer to pointers) if it helps to distinguish the variable from some other local variable with a similar name.
Even this convention is discouraged when not necessary.
</li>
<li>
<b>Lowercase</b>
Use all lower case letters.
</li>
<li>
<b>Minimal use of single character variable names</b>.
Short variable names are preferred.
However, single character variable names should be avoided.
Exceptions to this include <code>i</code>, <code>j</code>, and <code>k</code> which are reserved only for use as loop indices
(part of our Fortran legacy).
</li>
<li>
<b>Minimal use of <code>'_'</code></b>.
Preferably there are no <code>'_'</code> separators within the name.
Long variable names might require some delimitation using <code>'_'</code>.
Long variable names, however, are discouraged.
</li>
</ul>
<center><tablewidth="60%"border=1>
<tr><tdbgcolor="white">
<p><fontcolor="red"><b>Incorrect</b></p>
<ul><pre>
uint32_t somefunction(int a, uint32_t dwBValue)
{
uint32_t this_is_a_long_variable_name = 1;
int i;
for (i = 0; i < a; i++)
{
this_is_a_long_variable_name *= dwBValue--;
}
return this_is_a_long_variable_name;
}
</ul></pre></font>
</td></tr>
<tr><tdbgcolor="white">
<p><fontcolor="green"><b>Correct</b></p>
<ul><pre>
uint32_t somefunction(int limit, uint32_t value)
{
uint32_t ret = 1;
int i;
for (i = 0; i < limit; i++)
{
ret *= value--;
}
return ret;
}
</ul></pre></font>
</td></tr>
</table></center>
<p>
<b>NOTE:</b>
You will see the local variable named <code>ret</code> is frequently used in the code base for the name of a local variable whose value will be returned or to received the returned value from a called function.
</p>
<h2>2.4 <aname="typedefinitions"> Type Definitions</a></h2>
<p><b>Coding Standard:</b></p>
<ul>
<li>
<b>Short type names</b>.
Type names should be terse, but generally descriptive of what the type is for.
Try to say something with the type name, but don't try to say too much.
For example, the type name of <code>fhandle_t</code> is preferable to something like <code>openfilehandle_t</code>.
</li>
<li>
<b>Type name suffix</b>.
All <code>typedef</code>'ed names end with the suffix <code>_t</code>.
</li>
<li>
<b>Module name prefix</b>
If a type belongs in a <i>module</i> with a name of, say <code>xyz</code>, then that module should be included as a prefix to the type name like: <code>xyz_</code>.
</li>
<li>
<b>Lowercase</b>.
Use all lower case letters.
</li>
<li>
<b>Minimal use of <code>'_'</code></b>.
Preferably there are few <code>'_'</code> separators within the type name.
Long type names might require some delimitation using <code>'_'</code>.
Long type names, however, are discouraged.
</li>
</ul>
<center><tablewidth="60%"border=1>
<tr><tdbgcolor="white">
<p><fontcolor="red"><b>Incorrect</b></p>
<ul><pre>
typedef void *myhandle;
typedef int myInteger;
</ul></pre></font>
</td></tr>
<tr><tdbgcolor="white">
<p><fontcolor="green"><b>Correct</b></p>
<ul><pre>
typedef FAR void *myhandle_t;
typedef int myinteger_t;
</ul></pre></font>
</td></tr>
</table></center>
<p>
<b>NOTE</b>:
See the discussion of <ahref="#farnear">pointers</a> for information about the <code>FAR</code> qualifier used above.
</p>
<h2>2.5 <aname="structures">Structures</a></h2>
<p><b>Structure Naming</b></p>
<ul>
<li>
<b>No un-named structures</b>.
All structures must be named, even if they are part of a type definition.
The reason for this is that is structure pointers may be forward referenced in header files without having to include the file the provides the type definition.
Structure names should be terse, but generally descriptive of what the structure contains.
Try to say something with the structure name, but don't try to say too much.
For example, the structure name of <code>xyz_info_s</code> is preferable to something like <code>xyz_datainputstatusinformation_s</code>.
</li>
<li>
<b>Structure name suffix</b>.
All structure names end with the suffix <code>_s</code>.
</li>
<li>
<b>Module name prefix</b>
If a structure belongs to a <i>module</i> with a name of, say <code>xyz</code>, then that module should be included as a prefix to the structure name like: <code>xyz_</code>.
</li>
<li>
<b>Lowercase</b>.
Use all lower case letters.
</li>
<li>
<b>Minimal use of <code>'_'</code></b>.
Preferably there are few <code>'_'</code> separators within the structure name.
Long variable names might require some delimitation using <code>'_'</code>.
Long variable names, however, are discouraged.
</li>
</ul>
<p><b>Structure Field Naming</b></p>
<ul>
<li>
<b>Common variable naming</b>.
Structure field naming is generally the same as for local variables.
</li>
<li>
<b>One definition per line</b>.
The <ahref="#onedatperline">one definition per line</a> rule applies to structure fields,
including bit field definitions.
</li>
<li>
<b>Each field should be commented</b>.
Each structure field should be commented.
Commenting should follow the <ahref="#comments">standard conventions</a>.
</li>
<li>
<b>Optional structure field prefix</b>.
It make be helpful to add a two-letter prefix to each field name so that is is clear which structure the field belongs to.
Although a good practice, that convention has not been used consistently in NuttX.
</li>
<li>
<b>Lowercase</b>.
Use all lower case letters.
</li>
<li>
<b>Minimal use of <code>'_'</code></b>.
Preferably there are few <code>'_'</code> separators within the field name.
Long variable names might require some delimitation using <code>'_'</code>.
Long variable names, however, are discouraged.
</li>
</ul>
<p>
<b>Other Applicable Coding Standards</b>.
See sections related to <ahref="#lines">line formatting</a>, <ahref="#braces">use of braces</a>, <ahref="#indentation">indentation</a>, and <ahref="#comments">comments</a>.
</p>
<p>
<b>Size Optimizations</b>.
When declaring fields in structures, order the declarations in such a way as to minimize memory waste due of data alignment.
This essentially means that that fields should be organized by data size, not by functionality:
Put all pointers togeter, all <code>uint8_t</code>'s together, all <code>uint32_t</code>'s together.
Data types withi well known like <code>uint8_t</code> and <code>uint32_t</code> should also be place in either ascending or descending size order.
Naming of unions and fields within unions follow the same naming rules as for <ahref="#structures">structures and structure fields</a>.
The only difference is that the suffix <code>_u</code> is used to identify unions.
</p>
<p>
<b>Other Applicable Coding Standards</b>.
See sections related to <ahref="#lines">line formatting</a>, <ahref="#braces">use of braces</a>, <ahref="#indentation">indentation</a>, and <ahref="#comments">comments</a>.
The only difference is that the suffix <code>_e</code> is used to identify an enumeration.
</p>
<p>
<b>Enumeration Value Naming</b>.
Enumeration values, however, following a naming convention more similar to <ahref="#macros">macros</a>.
</p>
<ul>
<li>
<b>Uppercase</b>.
Enumeration values are always in upper case.
</li>
<li>
<b>Use of <code>'_'</code> encouraged</b>.
Unlike other naming, use of the underscore character <code>_</code> to break up enumeration names is encouraged.
</li>
<li>
<b>Prefix</b>.
Each value in the enumeration should begin with an upper-case prefix that identifies the value as a member of the enumeration.
This prefix should, ideally, derive from the name of the enumeration.
</li>
<li>
<b>No dangling commas</b>.
There should be no dangling comma on the final value of the enumeration.
The most commonly used tool chain are tolerant of such dangling commas, but others will not.
</li>
</ul>
<p>
<b>Other Applicable Coding Standards</b>.
See sections related to <ahref="#lines">line formatting</a>, <ahref="#braces">use of braces</a>, <ahref="#indentation">indentation</a>, and <ahref="#comments">comments</a>.
There are a few lower case values in NuttX macro names. Such as a lower-case <code>p</code> for a period or decimal point (such as <code>VOLTAGE_3p3V</code>).
I have also used lower-case <code>v</code> for a version number (such as <code>CONFIG_NET_IPv6</code>).
However, these are exceptions to the rule rather than illustrating a rule.
</li>
<li>
<b>Macros that could be functions</b>.
Lower-case macro names are also acceptable if the macro is a substitute for a function name that might be used in some other context.
In that case, normal function naming applies.
</li>
<li>
<b>Use of <code>'_'</code> encouraged</b>.
Unlike other naming, use of the underscore character <code>_</code> to break up macro names is encouraged.
</li>
<li>
<b>Prefix</b>.
Each related macro value should begin with an upper-case prefix that identifies the value as part of a set of values (and also to mimimize the likelihood of naming collisions).
</li>
<li>
<b>Single space after <code>#define</code></b>.
A single space character should separate the <code>#define</code> from the macro name.
Tabs are never used.
</li>
<li>
<b>Normal commenting rules</b>.
Normal commenting rules apply.
</li>
<li>
<b>Line continuations</b>.
Macro definitions may be continued on the next line by terminating the line with the <code>\</code> character just before the newline character.
There should be a single space before the <code>\</code> character.
Aligned <code>\</code> characters on multiple line continuations are discouraged because they are a maintenance problem.
</li>
<li>
<b>Parentheses around macro argument expansions</b>.
Macros may have argument lists.
In the macros expansion, each argument should be enclosed in parentheses.
</li>
<li>
<b>Real statements</b>.
If a macro functions as a statement, then the macro expansion should be wrapped in <code>do { ... } while (0)</code> to assume that the macros is, indeed, a statement.
</li>
<li>
<b><i>Magic numbers</i> are prohibited in code</b>.
Any numeric value is not intuitively obvious, must be properly named and provided as either a pre-processor macro or an enumeration value.
Pointers following same naming conventions as for other variable types.
A pointer (or pointer-to-a-pointer) variable may be prefaced with <code>p</code> (or <code>pp</code>) with no intervening underscore character <code>_</code> in order to identify that variable is a pointer.
That convention is not encouraged, however, and is only appropriate if there is some reason to be concerned that there might otherwise be confusion with another variable that differs only in not being a pointer.
<p>
<b>White Space</b>.
The asterisk used in the declaration of a pointer variable or to dereference a pointer variable should be placed immediately before the variable name with no intervening spaces.
A space should precede the asterisk in a cast to a pointer type.
</p>
<center><tablewidth="60%"border=1>
<tr><tdbgcolor="white">
<p><fontcolor="red"><b>Incorrect</b></p>
<ul><pre>
int somefunction(struct somestruct_s* psomething);
ptr = (struct somestruct_s*)value;
</ul></pre></font>
</td></tr>
<tr><tdbgcolor="white">
<p><fontcolor="green"><b>Correct</b></p>
<ul><pre>
int somefunction(FAR struct somestruct_s *something);
ptr = (FAR struct somestruct_s *)value;
</ul></pre></font>
</td></tr>
</table></center>
<p><aname="farnear">
<b><code>FAR</code>, <code>NEAR</code>, <code>DSEG</code> and <code>CODE</code> pointers</b></a>.
Some architectures require a qualifier on pointers to identify the address space into which the pointer refers.
The macros <code>FAR</code>, <code>NEAR</code>, <code>DSEG</code> and <code>CODE</code> are defined in <code>include/nuttx/compiler.h</code> to provide meaning for this qualifiers when needed.
For portability, the general rule is that pointers to data that may lie in the stack, heap, <code>.bss</code>, or <code>.data</code> should be prefaced by the qualifier <code>FAR</code>; pointers to functions probably lie in a code address space and should have the qualifier <code>CODE</code>.
The typical effect of these macros on architectures where they have meaning to determine the size of the pointer (size in the sense of the width of the pointer value in bits).
Each function is preceded by a function header. The function header is a <i>block comment</i> that provides information about the function.
The block comment consists of the following:
<p><ul>
<li>
The block comment begins with a line that consists of the opening C comment in column 1 (<code>/*</code>) followed by a series of asterisks extending to the length of the line (usually to column 78).
</li>
<li>
The block comment ends with a line that consists of series of asterisks beginning at column 2 and extending to the near the end line (usually to column 77) followed by the closing C comment in (usually at column 78 for a total length of 79 characters).
</li>
<li>
Information about the function is included in lines between the first and final lines.
Each of these begin with a space in column 1, an sterisk (<code>*</code>) in column 2, and a space in column 3.
</li>
</ul></p>
</li>
<li>
<b>Function header preceded by one blank line</b>.
Exactly one blank line precedes each function header.
</li>
<li>
<b>Function header followed by one blank line</b>.
Exactly one blank line is placed after function header and before the function definition.
</li>
<li>
<b>Function header sections</b>.
Within the function header, the following data sections must be provided:
<p><ul>
<li>
<b><code> * Name: </code></b> followed by the name of the function on the same line.
</li>
<li>
<b><code> * Description:</code></b> followed by a description of the function beginning on the second line.
Each line of the function description is indented by two additional spaces.
</li>
<li>
<b><code> * Input Parameters:</code></b> followed by a description of the of each input parameter beginning on the second line.
Each input parameter begins on a separator line indented by two additional spaces.
Function names should be terse, but generally descriptive of what the function is for.
Try to say something with the function name, but don't try to say too much.
For example, the variable name of <code>xyz_putvalue</code> is preferable to something like <code>xyz_savethenewvalueinthebuffer</code>.
</li>
<li>
<b>Lowercase</b>.
Use all lower case letters.
</li>
<li>
<b>Module prefix</b>.
All functions in the same <i>module</i>, or <i>sub-system</i>, or within the same file should have a name beginning with a common prefix separated from the remainder of the function name with the underscore, <code>'_'</code>, character.
For example, for a module called <i>xyz</i>, all of the functions should begin with <code>xyz_</code>.
</li>
<li>
<b>Extended prefix</b>.
Other larger functional grouping should have another level in the naming convention.
For example, if module <i>xyz</i> contains a set of functions that manage a set of I/O buffers (IOB), then those functions all should get naming beginning with a common prefix like <code>xyz_iob_</code>.
</li>
<li>
<b>Use of <code>'_'</code> discouraged</b>.
Further use of the <code>'_'</code> separators is discouraged in function naming.
Long function names might require some additional elimitation using <code>'_'</code>.
Long function names, however, are also discouraged.
</li>
<li>
<b>Verbs and Objects</b>.
The remainder of the function name should be either in the form of <i>verb-object</i> or <i>object-verb</i>.
It does not matter which as long as the usage is consistent within the <i>module</i>.
Common verbs include <i>get</i> and <i>set</i> (or <i>put</i>) for operations that retrieve or store data, respectively.
The verb <i>is</i> is reserved for functions that perform some test and return a boolean value to indicate the result of the test.
In this case, the <i>object</i> should indicate what is testing and the return value of <code>true</code> should be consistent with result of the test being true.
Because NuttX conforms to the older C89 standard, all variables that have scope over the compound statement must be defined at the beginning of the compound statement prior to any executable statements.
Local variable definitions intermixed within the following sequence of executable statements are forbidden.
A single blank line must follow the local variable definitions separating the local variable definitions from the following executable statements.
<b>NOTE</b> that a function body consists of a compound statement, but typically so does the statement following <code>if</code>, <code>else</code>, <code>for</code>, <code>while</code>, <code>do</code>.
Local variable definitions are also acceptable at the beginning of these compound statements as with any other.
The argument of the <code>return</code> statement should <i>not</i> be enclosed in parentheses.
A reasonable exception is the case where the returned value argument is a complex expression and where the parentheses improve the readability of the code.
Such complex expressions might be Boolean expressions or expressions containing conditions.
Simple arithmetic computations would not be considered <i>complex</i> expressions.
See sections related to <ahref="#general">General Conventions</a>, <ahref="#localvariable">Parameters and Local Variables</a>, and <ahref="#statements">Statements</a>.
All calls to <code>malloc</code> or <code>realloc</code>, in particular, must be checked for failures to allocate memory to avoid use of NULL pointers.
<h3>4.1 <aname="onestatement">One Statement Per Line</a></h3>
<p><b>Coding Standard:</b></p>
<ul>
<li>
<b>One statement per line</b>.
There should never be more than one statement on a line.
</li>
<li>
<b>No more than one assignment per statement</b>.
Related to this, there should never be multiple assignments in the same statement.
</li>
<li>
<b>Statements should never be on the same line as any keyword</b>.
Statements should never be on the same line as case selectors or any C keyword.
</li>
</ul>
<p>
<b>Other Applicable Coding Standards</b>.
See the section related to the use of <ahref="#braces">braces</a>.
</p>
<center><tablewidth="60%"border="1">
<tr><tdbgcolor="white">
<p><fontcolor="red"><b>Incorrect</b></p>
<ul><pre>
if (var1 < var2) var1 = var2;
case 5: var1 = var2; break;
var1 = 5; var2 = 6; var3 = 7;
var1 = var2 = var3 = 0;
</ul></pre></font>
</td></tr>
<tr><tdbgcolor="white">
<p><fontcolor="green"><b>Correct</b></p>
<ul><pre>
if (var1 < var2)
{
var1 = var2;
}
case 5:
{
var1 = var2;
}
break;
var1 = 5;
var2 = 6;
var3 = 7;
var1 = 0;
var2 = 0;
var3 = 0;
</ul></pre></font>
</td></tr>
</table></center>
<h2>4.2 <aname="casts">Casts</a></h2>
<p><b>Coding Standard:</b></p>
<ul>
<li>
<b>No space in cast</b>.
There should be no space between a cast and the value being cast.
</li>
</ul>
<center><tablewidth="60%"border=1>
<tr><tdbgcolor="white">
<p><fontcolor="red"><b>Incorrect</b></p>
<ul><pre>
struct something_s *x = (struct something_s*) y;
</ul></pre></font>
</td></tr>
<tr><tdbgcolor="white">
<p><fontcolor="green"><b>Correct</b></p>
<ul><pre>
struct something_s *x = (struct something_s *)y;
</ul></pre></font>
</td></tr>
</table></center>
<h2>4.3 <aname="operators">Operators</a></h2>
<p>
<b>Spaces before and after binary operators</b>.
All binary operators (operators that come between two values), such as <code>+</code>, <code>-</code>, <code>=</code>, <code>!=</code>, <code>==</code>, <code>></code>, etc. should have a space before and after the operator, for readability. As examples:
</p>
<center><tablewidth="60%"border=1>
<tr><tdbgcolor="white">
<p><fontcolor="red"><b>Incorrect</b></p>
<ul><pre>
for=bar;
if(a==b)
for(i=0;i>5;i++)
</ul></pre></font>
</td></tr>
<tr><tdbgcolor="white">
<p><fontcolor="green"><b>Correct</b></p>
<ul><pre>
for = bar;
if (a == b)
for (i = 0; i > 5; i++)
</ul></pre></font>
</td></tr>
</table></center>
<p>
<b>No space separating unary operators</b>.
Unary operators (operators that operate on only one value), such as <code>++</code>, should <i>not</i> have a space between the operator and the variable or number they are operating on.
Many operators are expressed as a character in combination with <code>=</code> such as <code>+=</code>, <code>>=</code>, <code>>>=</code>, etc.
Some compilers will accept the <code>=</code> at the beginning or the end of the sequence.
This standard, however, requires that the <code>=</code> always appear last in order to avoid amiguities that may arise if the <code>=</code> were to appear first. For example, <code>a =++ b;</code> could also be interpreted as <code>a =+ +b;</code> or <code>a = ++b</code> all of which are very different.
Statement(s) following the <code>if <condition></code> and <code>else</code> keywords must always be enclosed in braces.
Braces must follow the <code>if <condition></code> and <code>else</code> lines even in the cases where (a) there is no contained statement or (b) there is only a single statement!
That blank line must also be omitted for certain cases where the <code>if <condition></code>-<code>else</code> statement is nested within another compound statement; there should be no blank lines between consecutive right braces as discussed in the standard rules for use of <ahref="#braces">braces</a>.
By <i>case logic</i> it is mean the <code>case</code> or <code>default</code> and all of the lines of code following the <code>case</code> or <code>default</code> up to the next <code>case</code>, <code>default</code>, or the right brace indicating the end of the switch statement.
The final right brace that closes the <code>switch <value></code> statement must be followed by a single blank line.
</li>
<li>
<b>Exception</b>.
That blank line must be omitted for certain cases where the <code>switch <value></code> statement is nested within another compound statement; there should be no blank lines between consecutive right braces as discussed in the standard rules for use of <ahref="#braces">braces</a>.
The final right brace that closes the <code>while <condition></code> statment must be followed by a single blank line.
</li>
<li>
<b>Exception</b>.
That blank line must be omitted for certain cases where the <code>while <condition></code> statement is nested within another compound statement; there should be no blank lines between consecutive right braces as discussed in the standard rules for use of <ahref="#braces">braces</a>.
<h2>4.8 <aname="goto">Use of <code>goto</code></a></h2>
<p><b>Coding Standard:</b></p>
<ul>
<li>
<b>Limited Usage of <code>goto</code></b>.
All use of the <code>goto</code> statement is prohibited except for one usage:
for handling error conditions in complex, nested logic.
A simple <code>goto</code> in those conditions can greatly improve the readability and complexity of the code.
</li>
<li>
<b>Label Naming</b>.
Labels must all lower case.
The underscore character <code>_</code> is permitted to break up long labels.
</li>
<li>
<b>Error Exit Labels</b>.
The error exit label is normally called <code>errout</code>.
Multiple error labels are often to required to <i>unwind</i> to recover resources committe in logic prior to the error to otherwise <i>undo</i> preceding operations.
Naming for these other labels would be some like <code>errout_with_allocation</code>, <code>errout_with_openfile</code>, etc.
<p><i>All global functions in the file are prototyped here. The keyword <code>extern</code> or the definition <code>EXTERN</code> are never used with function prototypes.</i></p>
<pre>
#undef EXTERN
#ifdef __cplusplus
}
#endif
#endif /* __INCLUDE_ASSERT_H */
</pre>
<p><i>Ending with the header file <ahref="#idempotence">idempotence</a><code>#endif</code>.</i></p>
