Rules:

7.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, including specifically K&R C and C99. Restricted names include interrupt, inline, restrict, class, true, false, public, private,friend, and protected.

7.1.b. No variable shall have a name that overlaps with a variable name from the C Standard Library (e.g., errno).

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

7.1.d. No variable name shall be longer than 31 characters.

7.1.e. No variable name shall be shorter than 3 characters, including loop counters.

7.1.f. No variable name shall contain any uppercase letters.    

7.1.g. No variable name shall contain any numeric value that is called out elsewhere, such as the number of elements in an array or the number of bits in the underlying type.

7.1.h. Underscores shall be used to separate words in variable names.

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

7.1.j. The names of any global variables shall begin with the letter ‘g’. For example, g_zero_offset.

7.1.k. The names of any pointer variables shall begin with the letter ‘p’. For example, p_led_reg.

7.1.l. The names of any pointer-to-pointer variables shall begin with the letters ‘pp’. For example, pp_vector_table.

7.1.m. The names of all integer variables containing Boolean information (including 0 vs. non-zero) shall begin with the letter ‘b’ and phrased as the question they answer. For example, b_done_yet or b_is_buffer_full.

7.1.n. The names of any variables representing non-pointer handles for objects, e.g., file handles, shall begin with the letter ‘h’. For example, h_input_file.

7.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].

Example: See Appendix D.

Reasoning: The base rules are adopted to maximize code portability across compilers. Many C compilers recognize differences only in the first 31 characters in a variable’s name and reserve names beginning with an underscore for internal names.

The other rules are meant to highlight risks and ensure consistent proper use of variables. For example, all code relating to the use of global variables and other singleton objects, including peripheral registers, needs to be carefully considered to ensure there can be no race conditions or data corruptions via asynchronous writes.

Enforcement: These rules shall be enforced during code reviews.