Coding guidelines are intended to promote source code that is understandable, maintainable, testable, and error-free. This article describes the regulatory requirements for coding guidelines and provides specific examples.

1. Regulatory requirements for coding guidelines

1.1. Requirements of the Medical Device Regulation (MDR)

The Medical Device Regulation MDR (2017/745) requires the following for medical devices that contain software or are standalone software:

For devices that incorporate software or that are software in themselves, the software is developed and manufactured by the state of the art, taking into account the principles of the software life cycle and risk management, including information security, verification, and validation.

As with the Medical Devices Directive, in the event of a legal dispute, an expert should be able to confirm that the use of coding guidelines is part of the “state of the art”.

1.2. Requirements of IEC 62304

First, the good news is that IEC 62304 does not require any coding guidelines. It only requires that acceptance criteria be formulated and checked for the software units. IEC 62304 only writes in a note: “Examples of acceptance criteria are […] Does the software code comply with defined programming procedures and coding standards?”

1.3. FDA coding guidelines

Likewise, the FDA does not require that coding guidelines be followed. However, the FDA writes in the Software Validation Guidance Document:

The software design specification should include: […] Development procedures and coding guidelines (or other programming procedures); […]  Firms frequently adopt specific coding guidelines that establish quality policies and procedures related to the software coding process. Source code should be evaluated to verify its compliance with specified coding guidelines. Such guidelines should include coding conventions regarding clarity, style, complexity management, and commenting. Code comments should provide useful and descriptive information for a module, including expected inputs and outputs, variables referenced, expected data types, and operations to be performed. Source code should also be evaluated to verify its compliance with the corresponding detailed design specification. Modules ready for integration and test should have documentation of compliance with coding guidelines and any other applicable quality policies and procedures.

1.4. Conclusion

Coding guidelines are not explicitly required. However, it represents the state of the art. Medical device manufacturers should, therefore, benefit from coding guidelines. There are no specific requirements, such as a list of applicable coding guidelines.

2. Coding Guidelines

2.1. Examples

In general, coding guidelines can address the following aspects:

• Formatting: indentation, use of spaces and tabs, blank lines, etc.
• Metrics: length of classes, methods/functions, and lines, nesting depth, cyclomatic complexity, number of atomic conditions, number of transfer parameters, etc.
• Documentation: inline, functions/methods, classes
• Naming conventions: upper and lower case, meaningful names,
• Other: variable declarations, error handling, internationalization

The figure above also shows examples. For platform-specific coding guidelines, the tools listed below provide further information.

2.2. NASA Coding Guidelines

There are specific programming requirements, especially in safety-critical areas such as rail traffic, power plants, aviation, and aerospace. In “The Power of Ten – Rules for Developing Safety Critical Code”, Gerard J. Holzmann lists the following best practices:

1. Simple control constructs. No goto programming, no recursion.
2. All loops must have a fixed upper limit.
3. No dynamic memory allocation after initialization
4. No method is printed longer than one page
5. At least two “assertions” per method/function
6. Objects must be declared locally if possible. Global variables are the opposite of this.
7. Return values of non-void functions must be evaluated
8. The use of preprocessors should be limited to including header files and simple macro definitions
9. The use of pointers should be minimized
10. All code must be compiled with the strictest compiler warnings from the start

This list suggests the author has the C language in mind rather than a.NET language or Java.

3. The purpose of coding guidelines

The coding guidelines essentially pursue the following objectives:

1. They are intended to increase the code’s readability, comprehensibility, changeability, and thus maintainability. According to the FDA, 79% of errors (and efforts?) occur in this phase.
2. They are intended to minimize errors in the code (from the very beginning).
3. Improve the efficiency and effectiveness of code reviews (and thus the quality of the code again)

3.1. Coding guidelines simplify code reviews

The purpose of a code review is to find bugs. These reviews are practical and efficient when the reviewer does not have to think like the developer. Code reviews involve pattern recognition. Reviewers have to be able to look at the code and immediately—even unconsciously—perceive where something is wrong.

Good developers can do that. However, this only works if the inner algorithm for pattern recognition always receives the same input signal. That includes coding guidelines, especially formatting such as parentheses, spaces, indentations, etc. Otherwise, the algorithm will come to nothing. It would be the same with my hairdresser if the pictures were displayed not in white on black but in black on white or swapped left and right.

3.2. Example: Apple’s SSL bug

The waves were high because of the Apple SSL bug, which is not surprising given its seriousness. A non-functioning review of the certificates undermines the entire security concept.

The lesson from this incident is that coding and formatting guidelines should be sensible and binding. In all probability, this error would have been noticed without a test (!!) if it had been required that

1. Conditions must always be enclosed in curly brackets,
2. The code must be automatically formatted or at least correctly indented,
3. The code is subjected to an automatic and static code analysis for violations of the coding guidelines and
4. The code is subjected to a code review that includes the coding guidelines and the results of the static code analysis.

This mistake is a standard one that I have made countless times – until I followed the rules above.

Since the first three points can be carried out or checked automatically, I see no reason to do so without coding guidelines and a code analysis.

4. Tools for the review of coding guidelines

Some coding guidelines are independent of the programming language, while others are specific. Wikipedia lists various tools for reviewing coding guidelines, sorted by programming language.