Medical device manufacturers ask me regularly in my free audit consultation which coding guidelines we should observe. This article provides answers.
Demands of the IEC 62304
The good news: The IEC 62304 does not require that any coding guidelines were complied with. It only demands that acceptance criteria must be formulated to the software units and tested. The IEC 62304 only writes in a note: Examples of acceptance criteria are: [...] Corresponds to the software code established programming procedures and coding standards?
Regulations from the FDA for coding guidelines
Likewise, the FDA does not require that coding guidelines must be observed. 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.
In general, the coding guidelines can address the following aspects:
The illustration above also gives examples. For platform-specific coding guidelines the tools mentioned below give you further details.
The coding guidelines pursue two main objectives:
During code review errors should be found. These reviews are especially effective and efficient if the reviewer does not have to empathize in the specific world of thought of the developer. Code reviews have something to do with "Pattern Recognition". Reviewers need to look at the code and immediately - even unconsciously - perceive where something is not right.
Good developers can do that. That works only if the internal algorithm for pattern recognition always gets the same input signal. And this includes coding guidelines, above all formatting, such as clip settlements, spaces, indents, etc. Otherwise, the algorithm runs into the void. One would have the images not white on black but shown in black on white or right-left reversed.
Example: Apple's SSL Bug
The waves ran high because of Apple’s SSL Bugs. This is not really surprising. A non-functioning of the test certificates undermines the entire safety concept.
From this incident, one can take the lesson that coding guidelines and formatting guidelines should be meaningful and authentic, in my opinion. This error would indeed most likely have been noticed even without testing (!!), they would have demanded that
This error is indeed a standard error, which I myself have done countless times - until I followed the above rules.
Since the first three points are automatically carried out or can be checked, there is no reason to do without coding guidelines and a code analysis.
There are coding guidelines that apply regardless of the programming language, others are specific. Wikipedia lists a wide variety of tools for the inspection of coding guidelines sorted by programming language.