Barr Group TwitterBarr Group Vimeo

Rules:

6.1.a. No procedure shall have a name that is a keyword of any standard version of the C or C++ programming language. Restricted names include interrupt, inline, class, true, false, public, private, friend, protected, and many others.

6.1.b. No procedure shall have a name that overlaps a function in the C Standard Library. Examples of such names include strlen, atoi, and memset.

6.1.c. No procedure shall have a name that begins with an underscore.

6.1.d. No procedure name shall be longer than 31 characters.

6.1.e. No function name shall contain any uppercase letters.

6.1.f. No macro name shall contain any lowercase letters.

6.1.g. Underscores shall be used to separate words in procedure names.

6.i.h. Each procedure’s name shall be descriptive of its purpose. Note that procedures encapsulate the “actions” of a program and thus benefit from the use of verbs in their names (e.g., adc_read()); this “noun-verb” word ordering is recommended. Alternatively, procedures may be named according to the question they answer (e.g., led_is_on()).

6.1.i. The names of all public functions shall be prefixed with their module name and an underscore (e.g., sensor_read()).

Example: See Appendix D.

Reasoning: Good function names make reviewing and maintaining code easier (and thus cheaper). The data (variables) in programs are nouns. Functions manipulate data and are thus verbs. The use of module prefixes is in keeping with the important goal of encapsulation and helps avoid procedure name overlaps.

Enforcement: Compliance with these naming rules shall be established in the detailed design phase and be enforced during code reviews.

 

What’s happening and how it’s done. Get in the know.

Sign Up for Our Newsletter

Receive free how-to articles, industry news, and the latest info on Barr Group webinars and training courses via email. 

To prevent automated spam submissions leave this field empty.