CMSC 421: Principles of Operating Systems

Coding Standards

Every programming department has some set of standards or conventions that programmers are expected to follow. The purpose of these standards is 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!!!

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

It is your responsibility to understand these standards. If you have any questions, ask your instructor!

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 'nr' as in 'nrStudents'.
• Begin variable names with lowercase letters.
• 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

• Follow the Linux kernel-style, especially during the projects. See the official Linux style guide.

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 variable declarations from executable statements with a blank line.
• Use tabs for each level of indentation.
• Indent statements inside of a loop or part of an "if" structure.
• Use spaces around all operators. For example,

  x = y + 5; NOT x=y+5;

Use of Braces

• See the indentation standard for appropriate placement of braces.

Comments

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

File Header Comments

EVERY project file should contain an opening comment describing the contents of the file and other pertinent information. This "file header comment" MUST include the following information.

1. Your name,
2. Your email address, and
3. A description of what the program does.

For example,

/**
 * @Author George Burdell (gburdell@umbc.edu)
 * This file contains a program that gets two numbers from the
 * user and displays some statistics about the numbers.
 */
	

Function Header Comments

EACH FUNCTION must have a header comment that includes the following:

1. A description of what the function does,
2. A description of the function's inputs (if there are inputs),
3. A description of the function's outputs (if there are outputs), and
4. Side effect(s) of the function (if any -- this should be rare).

For example:

/**
 * area() - Calculate the area of a circle with the specified radius.
 *
 * @radius: measured in inches
 * Return: circle's area, measured in square inches
 */
	

The astute reader will recognize this as the Linux kernel commenting style. See the Linux commenting guide.