This post discusses some code review basics – concepts and inspection ideas that one might use when performing a code review.  A code review is a technical verification activity.  The purpose is most often to identify coding errors against the design intent – one is verifying that the code actually accomplishes what that author intended.  We might describe the activity as “verifying correctness” of the implemented code.  The particular inspection tasks one might use are listed later in this post.

There are many methods one can use to assure the quality of a distinct unit of code – code review is just one method.  There are many automated static analysis tools that can detect bugs, vulnerabilities, and code “smells.”  Often these tools can be integrated into a continuous build and integration environment.  These tools can range from simplistic to very advanced – and generally the price tag follows that progression as well.  However, if the tool finds and leads to the elimination of a single bug that could have ended up in the field – it likely pays for itself.

Unit testing, of course, is yet another method one should use in verifying correctness of implemented code.  A unit of code is a very small, discrete piece of functionality that the developer can fully understand and define testable behaviors that can be verified while executing the code.  The key here is dynamic execution.  Many behaviors of software are difficult to statically analyze – one must execute the code to verify.  A powerful addition to unit testing is to add test “hooks” that allow modification of inputs, injection of data, and monitoring of interim states and data values.

The driving principle of course is that software quality verification must occur as the code is written.  Don’t wait until large amounts of code are written and integrated before verifying correctness.  Quality cannot be “tested in.”  It must be designed in.  Often a developer can rationalize that quality attributes will be considered later during a hardening iteration or increment.  Many an experienced developer will say that the so-called hardening never occurs – schedule pressures and other priorities will prevent this remediation to occur.

So what are considerations and questions one might consider during a code review?

  1. Are the assumptions made in creating each routine documented in the source code header or design specification?
  2. Has the use of each variable with scope beyond function level in this component been justified?
  3. Are all output variables verified (implicitly or explicitly) before being returned?
  4. Is each variable used for one and only one purpose?
  5. Does the routine handle every possible set of input data?
  6. For data accessed by multiple routines (e.g., ISRs), document how the data is protected against corruption by asynchronous accesses.
  7. Has each variable been initialized before being used?
  8. Are variables appropriately named and related to problem domain?
  9. Have all arrays been analyzed for boundary issues?
  10. Is code following structured design with single return points and no “goto” statements?
  11. Have all constants been tied to macros and commented appropriately?
  12. Have all state machines been documented with a state chart in the design specifications?
  13. Are state transitions limited to signal inputs and, at most, one attribute variable?
  14. Does state machine handle unexpected power loss?
  15. Is the software unit under review tied to an architectural description?
  16. Is there an API layer?  Does the API layer provide domain relevant names for public interfaces?
  17. Does NVM design have a robust scheme for handlind unexpected power loss?


  1. Are drivers specific to one hardware device only?
  2. Do the drivers include an initialization function?
  3. Do the drivers make “port safe” writes?
  4. Are signals properly filtered and approved by hardware designer?
  5. Are signal shorts and signal opens detected and reported by driver?
  6. Are signals put into safe state during reset?


About the author

Brian is a biomedical software engineer - whatever that is! Started writing machine code for the Intel 8080 in 1983. Still enjoys designing and developing code. But probably enjoys his garden more now and watching plants grow ... and grandkids grow!

SoftwareCPR Training Courses:

IEC 62304 and other emerging standards for Medical Device and HealthIT Software

Our flagship course for preparing regulatory, quality, engineering, operations, and others for the activities and documentation expected for IEC 62304 conformance and for FDA expectations. The goal is to educate on the intent and purpose so that the participants are able to make informed decisions in the future.  Focus is not simply what the standard says, but what is meant and discuss examples and approaches one might implement to comply.  Special deep discount pricing available to FDA attendees and other regulators.

3-days onsite with group exercises, quizzes, examples, Q&A.

Instructor: Brian Pate

Next public offering:  TBD

Email to request a special pre-registration discount.  Limited number of pre-registration coupons.

Registration Link:




Being Agile & Yet Compliant (Public or Private)

Our SoftwareCPR unique approach to incorporating agile and lean engineering to your medical device software process training course is now open for scheduling!

  • Agile principles that align well with medical
  • Backlog management
  • Agile risk management
  • Incremental and iterative software development lifecycle management
  •  Frequent release management
  • And more!

2-days onsite (4 days virtual) with group exercises, quizzes, examples, Q&A.

Instructors: Mike Russell, Ron Baerg

Next public offering: March 7 & 28, 2024

Virtual via Zoom

Registration Link:

Register Now



Medical Device Cybersecurity (Public or Private)

This course takes a deep dive into the US FDA expectations for cybersecurity activities in the product development process with central focus on the cybersecurity risk analysis process. Overall approach will be tied to relevant standards and FDA guidance documentation. The course will follow the ISO 14971:2019 framework for overall structure but utilize IEC 62304, IEC 81001-5-1, and AAMI TIR57 for specific details regarding cybersecurity planning, risk characterization, threat modeling, and control strategies.

2-days onsite with group exercises, quizzes, examples, Q&A.

Instructor: Dr Peter Rech, 2nd instructor (optional)

Next public offering:  TBD

Corporate Office

15148 Springview St.
Tampa, FL 33624
Partners located in the US (CA, FL, MA, MN, TX) and Canada.