EE382C Embedded Software Systems - C/C++ Coding Tips

In grading programming assignments from previous versions of this course involving writing C/C++ code, I have compiled a list of comments when I graded and reviewed the submitted code.

Portability

• Use only standard ANSI C/C++ declarations and functions for portability. In the Spring 1999 course, no one used non-portable functions such as 'cfree' and not using non-portable variable declarations such as

    int tempWindow[size];
  

  instead of

    int* tempWindow = new int[size];
  

• Avoid templates. Templates are often overkill. Using template will cause the code to be incompatible with with older compilers. Templates were not standardized until the final ANSI C++ standard was adopted in December of 1997. Templates are incompatible with the CAD tool we'll be modifying in the class (Ptolemy).

Robust Code

• Avoid using global variables. In the Spring 1999 course, no one used global variables.
• Define local variables only when and where they are needed. Allocating variables outside the body in which they are used - your code will be much more efficient if you only allocate local variables in the body in which they are used, e.g.

  int i, j, index;
  for (i = 0; i < MAX_INDEX; i++) {
    for (j = 0; j < MAX_INDEX; j++) {
      index = i + j;
    }
  }
  

  would be compiled into more efficient code as

  int i;
  for (i = 0; i < MAX_INDEX; i++) {
    int j;
    for (j = 0; j < MAX_INDEX; j++) {
      int index = i + j;
    }
  }
  

• Initialize all local variables. Some people defined local variables without initializing them.
• Checking values of arguments. In the function to perform median filtering, many people did not check the length to make sure that it was greater than zero and did not check the value of the array pointer to make sure that it was not zero.
• Checking return values of functions. Some used calloc or malloc without checking to make sure that the returned values weren't null (zero). Strictly speaking, the same error checking should be performed with the new operator unless an exception handler for failed memory allocation has been defined by _new_handler. In the Ptolemy software environment, this has been defined.
• Array bounds errors. Some of the implementations could index an array out of range if one passed 1 for the median filter length. For example:

  if ( (window_size%2) == 0 ) window_size++;
  

• Use the correct version of delete. When deallocating an array, you should not do

  delete arrayName;
  

  but instead do

  delete [] arrayName;
  

  Also, as a precaution against freeing the same memory multiple times, set a pointer to zero after it has been deallocated.

Maintainability

• Follow C/C++ coding conventions. Define constants using completely upper case letters such as MAX_BUFFER_SIZE. Global and static variables should start with a package name followed by capital letter and then mixed case, e.g. PTWindow. Local variables should start with a lowercase letter and be mixed case, e.g. numberOfTaps.
• Generous use of constants. Many people put arbitrary constants in their code instead of defining constant names for them. By not defining constant names, the code becomes much harder to maintain.
• Reinventing the wheel. Many people wrote their own sorting routines instead of using the n log n sorting routine 'qsort' built into C. You could have found this routine by simply searching for sorting routines in the development environment, e.g. 'man -k sort' in Unix. Others wrote their own memory copy routines instead of using the ANSI C routine memcpy.