BARR1-3-a

Braces shall always surround the blocks of code following if, else, switch, while, do, and for statements.

Yes

BARR1-3-b

Each left brace ({) shall appear by itself on the line below the start of the block it opens. The corresponding right brace (}) shall appear by itself in the same position the appropriate number of lines later in the file.

Yes

BARR1-7-b

The register keyword shall not be used.

Yes

BARR2-1-b

Comments shall never contain the preprocessor tokens.

Yes

BARR3-6-a

Whenever possible, all source code lines shall end only with the single character ‘LF’ (ASCII 0x0A), not with the pair ‘CR’-‘LF’ (0x0D 0x0A).

Yes

BARR4-1-a

All module names shall consist entirely of lowercase letters, numbers, and underscores. No spaces shall appear within the module’s header and source file names.

No

BARR4-1-c

No module header file name shall share the name of a header file from the C Standard Library or C++ Standard Library.

Yes

BARR4-3-e

Each source file shall be free of unused include files.

No

BARR5-2-b

The keywords short and long shall not be used.

Yes

BARR5-3-b

None of the bitwise operators shall be used to manipulate signed integer data.

Yes

BARR7-2-a

All variables shall be initialized before use.

Yes

BARR8-5-b

C Standard Library functions abort(), exit(), setjmp(), and longjmp() shall not be used.

Yes

BARR1-4-a

Do not rely on C operator precedence rules, as they may not be obvious to those who maintain the code. Use parentheses to ensure proper execution order within a sequence of operations.

Assisted

BARR1-1-b

Whenever a C++ compiler is used, appropriate compiler options shall be set to restrict the language to the selected version of ISO C.

Unassisted

BARR1-1-d

Preprocessor directive #define shall not be used to alter or rename any keyword or other aspect of the programming language.

Assisted

BARR1-5-a

Abbreviations and acronyms should generally be avoided unless their meanings are widely and consistently understood in the engineering community.

Unassisted

BARR1-6-a

Each cast shall feature an associated comment describing how the code ensures proper behavior across the range of possible values on the right side.

Assisted

BARR1-7-d

It is a preferred practice to avoid all use of the continue keyword.

Assisted

BARR1-8-b_i

The const keyword shall be used to declare variables that should not be changed after initialization.

Assisted

BARR1-8-b_iii

The const keyword shall be used to define fields in a struct or union that should not be modified.

Unassisted

BARR1-8-c_i

The volatile keyword shall be used to declare a global variable accessible by any interrupt service routine.

Unassisted

BARR1-8-c_iii

The volatile keyword shall be used to declare a pointer to a memory-mapped I/O peripheral register set.

Unassisted

BARR2-1-c_i

Code shall never be commented out, even temporarily.

Assisted

BARR2-2-a

All comments shall be written in clear and complete sentences, with proper spelling and grammar and appropriate punctuation.

Unassisted

BARR2-2-c

end-of-line comments should only be used where the meaning of that one line of code may be unclear from the variable and function names and operations alone.

Unassisted

BARR2-2-e

Whenever an algorithm or technical detail is defined in an external reference, a comment shall include a sufficient reference to the original source to allow a reader of the code to locate the document.

Unassisted

BARR2-2-g

All assumptions shall be spelled out in comments.

Unassisted

BARR2-2-i_i

Use the following capitalized comment markers “WARNING:” to highlight alerts a maintainer there is risk in changing this code.

Unassisted

BARR2-2-i_iii

Use the following capitalized comment markers “TODO:” to highlight an area of the code is still under construction and explains what remains to be done.

Unassisted

BARR3-1-b

Each of the assignment operators =, +=, -=, *=, /=, %=, &=, |=, ^=, ~=, != shall always be preceded and followed by one space.

Assisted

BARR3-1-d

Each of the unary operators +, -, ++, --, ! , ~ shall be written without a space on the operand side.

Assisted

BARR3-1-f

The ? and : characters that comprise the ternary operator shall always be preceded and followed by one space.

Unassisted

BARR3-1-h

The left and right brackets of the array subscript operator ([ and ]) shall be without surrounding spaces, except as required by another white space rule.

Unassisted

BARR3-1-j

The left and right parentheses of the function call operator shall always be without surrounding spaces, except that the function declaration shall feature one space between the function name and the left parenthesis to allow that one particular mention of the function name to be easily located.

Unassisted

BARR3-1-l

Each semicolon separating the elements of a for statement shall always be followed by one space.

Unassisted

BARR3-2-a

The names of variables within a series of declarations shall have their first characters aligned.

Assisted

BARR3-2-c

The assignment operators within a block of adjacent assignment statements shall be aligned.

Unassisted

BARR3-3-a

No line of code shall contain more than one statement.

Assisted

BARR3-3-c

Each source file shall terminate with a comment marking the end of file followed by a blank line.

Assisted

BARR3-4-b

Within a switch statement, the case labels shall be aligned and the contents of each case block shall be indented once from there.

Assisted

BARR4-2-a

There shall always be precisely one header file for each source file and they shall always have the same root name.

Unassisted

BARR4-2-c_i

The header file shall identify only the procedures, constants, and data types about which it is strictly necessary for other modules to be informed. It is a preferred practice that no variable ever be declared (via extern) in a header file.

Assisted

BARR4-2-d

No public header file shall contain a #include of any private header file.

Unassisted

BARR4-3-b

Each source file shall be comprised of some or all of the following sections, in the order listed: comment block, include statements, data type, constant, and macro definitions, static data declarations, private function prototypes, public function bodies, then private function bodies.

Unassisted

BARR4-3-d

Absolute paths shall not be used in include file names.

Assisted

BARR4-4-a

A set of templates for header files and source files shall be maintained at the project level.

Unassisted

BARR5-1-c

The name of all public data types shall be prefixed with their module name and an underscore.

Unassisted

BARR5-2-c

Use of the keyword char shall be restricted to the declaration of and operations concerning strings.

Assisted

BARR5-4-b_i

Use the C99 type names for fixed point datatypes.

Assisted

BARR5-4-b_iii

Ensure that the compiler supports double precision.

Unassisted

BARR5-4-b_v

Always invoke the isfinite() macro to check that prior calculations have resulted in neither INFINITY nor NAN.

Unassisted

BARR5-5-b

Appropriate care shall be taken to prevent the compiler from altering the intended order of the bits within bit-fields.

Assisted

BARR5-6-b

Non-Boolean values shall be converted to Boolean via use of relational operators, not via casts.

Assisted

BARR6-1-b

No procedure shall have a name that overlaps a function in the C Standard Library.

Assisted

BARR6-1-d

No procedure name shall be longer than 31 characters.

Assisted

BARR6-1-f

No macro name shall contain any lowercase letters.

Assisted

BARR6-1-h

Each procedure’s name shall be descriptive of its purpose.

Unassisted

BARR6-2-a

All reasonable effort shall be taken to keep the length of each function limited to one printed page, or a maximum of 100 lines.

Assisted

BARR6-2-c

It is a preferred practice that all functions shall have just one exit point and it shall be via a return at the bottom of the function.

Assisted

BARR6-2-e

All private functions shall be declared static.

Assisted

BARR6-3-a

Parameterized macros shall not be used if a function can be written to accomplish the same behavior.

Assisted

BARR6-3-b_ii

Surround each use of a parameter with parentheses in parameterized macros.

Assisted

BARR6-3-b_iv

Never include a transfer of control in parameterized macros.

Assisted

BARR6-5-a

Interrupt service routines (ISRs) are not ordinary functions. The compiler must be informed that the function is an ISR by way of a #pragma or compiler-specific keyword.

Unassisted

BARR6-5-c

To ensure that ISRs are not inadvertently called from other parts of the software, each ISR function shall be declared static and/or be located at the end of the associated driver module as permitted by the target platform.

Unassisted

BARR7-1-a

No variable shall have a name that is a keyword of C, C++, or any other well-known extension of the C programming language.

Assisted

BARR7-1-c

No variable shall have a name that begins with an underscore.

Assisted

BARR7-1-e

No variable name shall be shorter than 3 characters.

Assisted

BARR7-1-g

No variable name shall contain any numeric value that is called out elsewhere.

Unassisted

BARR7-1-i

Each variable’s name shall be descriptive of its purpose.

Unassisted

BARR7-1-k

The names of any pointer variables shall begin with the letter ‘p’.

Assisted

BARR7-1-m

The names of all integer variables containing Boolean information shall begin with the letter ‘b’.

Assisted

BARR7-1-o

In the case of a variable name requiring multiple of the above prefixes, the order of their inclusion before the first underscore shall be [g][p|pp][b|h].

Unassisted

BARR7-2-c

If project- or file-global variables are used, their definitions shall be grouped together and placed at the top of a source code file.

Unassisted

BARR8-1-a

The comma operator shall not be used within variable declarations.

Unassisted

BARR8-2-b

Nested if…else statements shall not be deeper than two levels.

Assisted

BARR8-2-d

Any if statement with an else if clause shall end with an else clause.

Assisted

BARR8-3-b

All switch statements shall contain a default block.

Assisted

BARR8-4-a

Magic numbers shall not be used as the initial value or in the endpoint test of a while, do…while, or for loop.

Unassisted

BARR8-4-c

Infinite loops shall be implemented via controlling expression for (;;).

Assisted

BARR8-6-a

When evaluating the equality of a variable against a constant, the constant shall always be placed to the left of the equal-to operator (==).

Unassisted