Coding guidelines establish a standardized set of rules that facilitate the creation of maintainable, robust, and predictable code. These guidelines transcend mere stylistic recommendations. The consistency promoted and enforced by the guidelines mitigates misunderstandings among developers, facilitates the onboarding of new team members, and contributes to the sustained quality of code in large or distributed projects. In light of the complexity of parallel programming, and as new talent adopts NVIDIA CUDA, guidelines and automated tools play a key role in ensuring code quality and rapid adoption.
In the context of CUDA development, where performance and parallelism in particular increase intricacy, guidelines also help avoid subtle bugs that might only manifest at scale or under specific execution conditions.
Starting with the migration of CPU based high-performance computing code to GPU accelerated computing, GPUs today are no longer confined to graphics and high-performance computing. They now serve as accelerators enabling safety-critical systems such as ADAS (Advanced Driver Assistance Systems) and industrial and medical robotics. “Safety First” is the motto when transitioning to the era of physical AI to meet a wide range of standards. This shift brings new challenges with meeting safety certification requirements with GPU-based software.
As CUDA plays an ever-bigger role in these environments, the user community needs clear, enforceable coding rules to ensure not only performance and efficiency but reliability and safety as well.
Industries such as automotive, aerospace, industrial automation, and medical devices are governed by strict safety standards (e.g., ISO 26262, IEC 62304, IEC 61508). In these environments, software failures can lead to critical safety hazards. Coding guidelines are not optional here—they are mandated by certification processes to:
It is no longer sufficient for the QA function to identify bugs but rather developers are now responsible for providing evidence for the absence of flaws. Additionally, safety must be considered even when SW is operating as intended without faults or failures. Coding guidelines are developed by and for the industry experts to support the validation and verification process and serve as an essential tool for achieving the required level of quality and transparency.
Now that CUDA is increasingly used within regulated industries, e.g., for real-time perception in autonomous vehicles or advanced diagnostics in healthcare, safety-compliant CUDA development requires adherence to NVIDIA CUDA Coding Guidelines (NCCG) that NVIDIA recently provided to the user community.
Several well-established coding guideline sets are available for C and C++ which form the basis of CUDA development:
These rulesets vary in scope, but they share the goal of preventing unsafe constructs and improving code readability and reliability. A subtle point when applying the guidelines: developers not only have to consider the current version of the code but also need to think about future changes and how to minimize the risk introduced to seemingly unrelated parts of their systems.
The small snippets of code included below already demonstrate non-compliant behavior.
CUDA 4.2 – Click on Images to Enlarge
In such simplified cases, somebody could identify the issue during a manual, peer review and ask the author to fix it.
In practice, however, the code from the example above could be spread across different files and as such, there is the additional challenge if the scope of the review is system wide. Humans do not gravitate towards nor excel at the repetitive task of reviewing each code section against an extensive list of standards and guidelines. The limitation is clear: you simply cannot rely on manual reviews of all the project’s code for each and every change request.
The solution: extend automated checking to CUDA. Tools providing automated checking for standard C and C++ have become ubiquitous and as a first, Axivion CUDA NCCG Analyzer can automatically enforce the above CUDA-4.1 rule as well as the rest of the NCCG. When integrated into the CI&CD environment, Axivion reports violations back into the change request as annotations for the author or reviewer.
While the principles of code compliance also apply to CUDA, some aspects of it have an impact on static code analysis and had to be addressed.
Introducing coding guidelines into an existing project often reveals many violations. Attempting to fix everything at once is rarely practical and can be paralyzing. With Axivion, however, teams can approach this challenge in stages:
For many projects, it can be assumed to some extent that code from the past is “as it is” and is proven in use. So, rather than focusing on the full history of violations, Axivion’s novel delta analysis highlights changes introduced in each commit or merge request. Developers can then:
This is particularly useful in large CUDA projects where legacy code may or may not fully meet the now available guidelines, but new code is expected to comply. By nature, newer code is more risky than older code already “proven in use”.
Guideline enforcement works best when seamlessly integrated into the development and reviewing workflow. It begins at the at the user’s workstation:
The second line of defense is the CI/CD integration:
By embedding automated checking throughout the workflow, guideline compliance becomes a natural part of development rather than an afterthought. This does not only save time and reduce human errors but produce documentation useful for compliance certification.
“Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. ...[Therefore,] making it easy to read makes it easier to write.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship
Standardized rulesets like MISRA or NCCG are essential, but projects often require additional project-specific rules that are specific to their needs:
Custom guidelines: Rules on naming conventions, directory structures, or CUDA kernel launch patterns that reflect project-specific needs.
Such custom rules can easily be implemented in Axivion and the combination of standardized rules plus tailored extensions ensures that guidelines match both external certification requirements and internal project goals.
In larger CUDA projects, the complexity goes beyond coding rules. Axivion Architecture Verification feature checks if the software structure as implemented aligns with design specifications, safety concepts, and intended modularization and as such contributes to assure the Freedom From Interference (FFI) in safety architectures. By strictly monitoring the interactions of architectural components in different safety levels, automated architecture verification can detect all unintended dependencies, layering violations, or architectural drift—issues that are critical in regulated domains.