CMSC 104 - C Coding Standards

General Comments

Every programming department has some set of standards or conventions that programmers are expected to follow. The purpose of these standards is to make programs readable and maintainable. After all, you may be the programmer who maintains your own code more than six months after having written the original. While no two programming departments' standards/conventions may be the same, it is important that all members of the department follow the same standards. Neatness counts! At UMBC, the following standards have been created and are followed in CMSC 104 and CMSC 201.

Part of every project grade is based upon how well these standards are followed.

Naming Conventions

• Use meaningful variable names.
  For example, if your program needs a variable to represent the radius of a circle, call it 'radius', NOT 'r' and NOT 'rad'. The use of single letter variables is forbidden, except as simple 'for' loop indices. The use of obvious, common, meaningful abbreviations is permitted. For example, 'number' can be abbreviated as 'num' as in 'numStudents'.
• Begin variable names with lowercase letters
• Begin function names with uppercase letters
• Use all uppercase for symbolic constants (#define)
• Use all uppercase for typedefs
• Do not use global variables
• Be consistent!
• Separate "words" within identifiers with underscores or mixed upper and lowercase. Examples:
  2-"word" variable name: grandTotal or grand_total
  2-"word" function name: ProcessError or Process_Error

Use of Whitespace

The prudent use of whitespace (blank lines as well as space) goes a long way to making your program readable.

• Use blank lines to separate major parts of a source file or function.
• Separate declarations from executable statements with a blank line.
• DO NOT use tabs (unless your text editor changes tabs to 3 or 4 spaces). Tabs may be interpreted differently by different editors.
• Use 3 or 4 spaces for each level of indentation and be consistent.
• Preprocessor directives, function prototypes, and headers of function definitions begin in column 1.
• All statements in the body of a function are indented 3 or 4 spaces. Statements inside of a loop or part of an "if" structure are indented further.
• Use spaces around all operators. For example, write x = y + 5;, NOT x=y+5;
• Using the emacs or xemacs editor along with the .emacs file provided for you will automatically indent your code appropriately. The pico editor will not do so.

Use of Braces

• Always use braces to mark the beginning and end of a loop or "if" structure, even when not required.
• See the indentation styles for appropriate placement of braces.

Comments

Comments are the programmer's main source of documentation. Comments for files, functions, and code are described below.

File Header Comments

1. The file name
2. Your name
3. The date the file was created
4. Your section number
5. Your UMBC e-mail address
6. A description of what the code is and what it does

Function Header Comments

1. The function name
2. A description of what the function does
3. A description of the function's inputs
4. A description of the function's outputs
5. Side effect(s) of the function (if any -- this should be rare)

In-Line Comments

An in-line comment appears above the code to which it applies and is indented to the same level as the code. For example:

Comments for #defines and Variables

For example,