Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Embedded

What to ask during code reviews

Posted: 14 May 2015 ?? ?Print Version ?Bookmark and Share

Keywords:C code? compile? microcontroller? MCU? RTOS?

Over the years I have noticed a number of common gotchas when reviewing code. They're there no matter what the size the company or how mature the development process (and I have had the opportunity to review software for companies ranging from those with strict and bureaucratic processes to those that are more shoot-first-aim-later). In order to help alleviate these common issues, there are 10 questions that can be asked while reviewing C code to help find potential bug-ridden areas.

Question #1: Does the program build without warnings?
Code cannot be loaded on a target without a successful compile. A successful compile involves the programmer diligently removing any syntax errors in order to make the compiler happy and have it create an output file. But a compiler can build an application without error yet still find other anomalies, such as an implicit cast, that it reports as a warning. A truly successful compilation of a program, then, should involve not just compiling with zero errors but also with zero warnings. This definition of successful compilation may seem obvious, but failure to resolve warnings is an error that I continue to see from both green and senior engineers alike. The worst case I have seen had more than 100 warnings! The most disturbing case had just one: a simple implicit cast warning of an unsigned integer into a float.

Question #2: Are there any blocking functions?
One of the primary purposes of a microcontroller (MCU), in my opinion, is to be able to handle real-time events. MCUs should be able to handle those events in a very deterministic manner that can be measured and proven. Yet one of the common mistakes that I often see is that a driver or some application code segment is written such that it enters a loop or calls a delay function for an extended period of time. But a loop or delay prevents any other code from running on the processor, potentially compromising determinism. Button debounce functions are a notorious example. Instead of polling the GPIO pin or setting up an interrupt, many debounce implementations read the pin, then enter a delay of 20, 30, maybe even 40 milliseconds before reading the pin again. Take a look at Figure 1 for an example. In an environment without an RTOS this delay is the death of a real-time system.

Figure 1: GPIO debounce by blocking.

Question #3: Are there any potential infinite loops?
Who in their right mind would put an infinite loop into their code on purpose? (Excluding of course those needed in tasks or the application's main loop.) Yet there is a lot of example code on the web and from silicon vendors that exhibits an infinite loop failure behavior. For example, code that writes data to flash or EEPROM typically will monitor a hardware flag for completion. Example code will create a while loop on the flag to reach a certain state before proceeding. But if the hardware fails and the flag never gets set, the code becomes stuck in an infinite loop! An example of this can be seen in Figure 2.

Figure 2: Infinite loop hardware failure.

1???2?Next Page?Last Page

Article Comments - What to ask during code reviews
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top