In any high-level language, there are hundreds of instructions and constructs. Some of them are very easy to get wrong (especially in C and C++) and their incorrect use can lead to problems. Coding standards (also known as language subsets) were introduced to disallow the use of those error-prone functions and hence make the resulting code more likely to be error free. In short, they help developers write better, more reliable code.
All coding standards consist of rules and guidelines each of which supports an underlying set of guiding principles. Different coding standards have different primary aims, and so the benefits can differ between them. However, because they are all focused on embedded programming best practices, there is more commonality than difference.
In general, they promote:
Irrespective of programming language, most standards focus on practical rules relating to all aspects of the software developers’ work – syntax, semantics, data types, header file use, and so on.
These benefits are reflected in the fact that most safety-critical embedded system developers are required to use them, including practitioners in military and aerospace applications.
Being coding standard compliant means that the source code of a software project adheres to a specific set of rules, guidelines, and conventions outlined in a coding standard. Some coding standards and guidelines have documented processes that dictate precisely what constitutes compliance, as exemplified by the MISRA Compliance:2020 document.
The world of critical embedded software systems is a maze of standards with their confusing names and numbers. Even more confusingly, several of these groups of standards are called different things by different people.
To clarify where coding standards fit, it is useful to consider their relationship with “process standards”. Process standards are lengthy documents full of guidelines and rules that dictate how to go about writing embedded software so that errors are minimized. The more critical the application, the more demanding the rules to be followed.
Most of those process standards are concerned with functional safety (including DO178C, IEC 61508, ISO 26262, IEC 62304, EN 50128…) Increasingly these standards are being complemented by cybersecurity standards, so that (for example) ISO/SAE 21434 complements the automotive functional safety standard ISO 26262.
Most process standards require that coding standards are to be used.
Coding standards consist of a collection of rules that developers are intended to follow as part of the development process– or to justify why they are not doing so. For example, consider C coding standards for embedded software development. MISRA C consists of a set of “guidelines” that are classified as being either “rules” or “directives”. CERT C includes “rules” and “recommendations”, and BARR group Embedded C Coding Standard consists of different “rule” groupings…
Although this differing terminology can be confusing, the benefits of adhering to coding standards and the principles they encompass are largely common to them all. In general rules are classified which helps to guide their use with respect to matters such as
The C and C++ languages are popular amongst embedded system developers because they are flexible, high performance, and allow easy access to the hardware.
However, these same attributes also make the use of these languages susceptible to error for the unwary. And both languages are known for their “gotchas” in the form of undefined, unspecified, and implementation-defined behaviour that can introduce errors or vulnerabilities – especially when portability is important.
There are several established standards which vary in popularity according to both geography and industrial sector. There is also ample opportunity to tune any one or a combination of them to in-house requirements.
Some standards are focused on either security, or safety. Others, like MISRA, cover both perspectives.
A common way to improve the consistency and overall quality of code is to assess it against industry- or company-defined standards. Such an approach makes it easy to maintain code because deficiencies can be quickly identified and corrected. Although compliance could be achieved through manual peer reviews, such a process is time-consuming and prone to error.
For many companies, coding standards compliance usually starts either with guidelines and rules developed in-house or with widely accepted rules from standards such as MISRA or CERT. Often in-house rules are combined with industry-standard rules to form a corporate standard that is appropriate for the needs of the organization.
LDRA have provided class-leading solutions for security and safety coding standards compliance for almost half a century. Our current offerings include:
Both options leverage a common, intuative user interface, and are configerable to exclude calls to non-compliant APIs, including calls to Real-Time Operating Systems (RTOS).
LDRA’s code visualization identifies exactly where the source code deviates from the standard so it can be rapidly addressed. While many rules checking tools are created equally (because they’re based on the same commercial third-party parsing engine), LDRA’s in-house parsing technology enables rapid response to variations in languages and language constructs. And a long involvement in standards organisations such as MISRA allows LDRA to be ready for new coding standards upon their release.
LDRA’s coding standards compliance tools allow developers to combine standards and define appropriate rule subsets, select individual rules, and add their own. Within the tool, it is easy to check for coding standards compliance to any single standard or combination of standards or subsets. When working with a legacy code base, it is even possible to check the compliance of a single code base with multiple standards to compare how the code fulfils each of them, and see how code might best be adapted to conform to one of them.
Email: info@ldra.com
EMEA: +44 (0)151 649 9300
USA: +1 (855) 855 5372
INDIA: +91 80 4080 8707