Create User-Defined Coding Standard from Existing Checkers
R2026bIf your project has internal coding guidelines that map to existing Polyspace®
Bug Finder™ checkers, you can bundle those checkers into a single user-defined coding standard. The coding standard is a .pschk file that you share with your team and use in your CI pipeline. In this workflow, you select, organize, and package existing checkers. You can also create your own checkers and include them in the same catalog. For more information, see Create Checkers.
This topic shows how to identify existing checkers, organize them into rules and sections, and package them into a coding standard. The example creates a standard called ProjectSafety with sections for memory safety, class design, and performance.
This topic uses Polyspace Query Language (PQL) to define the coding standard. For mapping to existing checkers, you do not need to learn the full language — the syntax shown here is all you need.
Find Existing Checkers for Your Rules
Before creating a coding standard, identify which existing Bug Finder checkers enforce each of your coding rules. You reference checkers by their Polyspace Query Language (PQL) name — an identifier that the packaging tool uses to locate and activate each checker.
You can find the PQL name of a checker in the Check Information section of its reference page. To find a reference page, search the documentation with the checker name or browse in Polyspace Bug Finder Results.
This table lists the PQL names for checker groups available in Polyspace Bug Finder:
| Standard | PQL Name |
|---|---|
| MISRA C:2012 | std.misra_c_2012 |
| MISRA C:2023 | std.misra_c_2023 |
| MISRA C:2025 | std.misra_c_2025 |
| MISRA C++:2023 | std.misra_cpp_2023 |
| AUTOSAR C++14 | std.autosar_cpp14 |
| CERT C | std.cert |
| CERT C++ | std.cert_cpp |
| CWE | std.cwe_native |
| Bug Finder defects | std.defects |
If you cannot find a good mapping by reviewing checker documentation, create a specification file containing noncompliant and compliant C/C++ code for your coding rule. Run Polyspace Bug Finder on the specification file with all checkers enabled and observe which checkers report violations on the noncompliant code but not on the compliant code. For more information on finding checkers, see Find Polyspace Bug Finder Checkers That Map to Coding Rules in User-Defined Coding Standard.
For this example, assume you have identified these mappings:
| Section | Rule ID | Description | Bug Finder Checker (PQL Name) |
|---|---|---|---|
| Memory | MEM_1 | Detect and handle memory allocation errors | std.cert_cpp.MEM52_CPP |
| Memory | MEM_2 | Do not use realloc | std.misra_c_2012.R21_3 |
| Class Design | CLASS_1 | Make a function a member only if it needs direct access to class representation | std.autosar_cpp14.M9_3_3 |
| Class Design | CLASS_2 | Make default operations consistent | std.defects.MOVE_OPERATION_USES_COPY, std.autosar_cpp14.A12_8_1, std.autosar_cpp14.A12_1_1 |
| Performance | PERF_1 | Do not use map when set suffices | std.defects.EXPENSIVE_USE_OF_MAP_INSTEAD_OF_SET |
| Performance | PERF_2 | Avoid expensive map bracket insertion | std.defects.EXPENSIVE_MAP_INSERT_OR_ASSIGN |
Initialize Coding Standard
Create a folder for the coding standard and initialize it:
mkdir ProjectSafety
cd ProjectSafety
polyspace-query-language initinit command creates the file main.pql. This file assembles the components of the coding standard into a .pschk file.Create Folder Structure
Create one folder per section. Each folder corresponds to a PQL package:
mkdir Memory ClassDesign PerformanceProjectSafety/ ├── main.pql ├── Memory/ ├── ClassDesign/ └── Performance/
Define Rules
In each section folder, create .pql files that define rules. Each rule maps to one or more existing Bug Finder checkers by PQL name. When a single coding rule maps to multiple checkers, list them all in the same rule.
Memory/MEM_1.pql:package Memory #[Description("Detect and handle memory allocation errors"), Id(MEM_1), Category("Safety")] rule MEM_1 = { std.cert_cpp.MEM52_CPP }Memory/MEM_2.pql:package Memory #[Description("Do not use realloc"), Id(MEM_2), Category("Safety")] rule MEM_2 = { std.misra_c_2012.R21_3 }ClassDesign/CLASS_1.pql:package ClassDesign #[Description("Make a function a member only if it needs direct access to class representation"), Id(CLASS_1), Lang(C++), Category("Design")] rule CLASS_1 = { std.autosar_cpp14.M9_3_3 }ClassDesign/CLASS_2.pql:package ClassDesign #[Description("Make default operations consistent"), Id(CLASS_2), Lang(C++), Category("Design")] rule CLASS_2 = { std.defects.MOVE_OPERATION_USES_COPY, std.autosar_cpp14.A12_8_1, std.autosar_cpp14.A12_1_1 }Performance/PERF_1.pql:package Performance #[Description("Do not use map when set suffices"), Id(PERF_1), Lang(C++), Category("Performance")] rule PERF_1 = { std.defects.EXPENSIVE_USE_OF_MAP_INSTEAD_OF_SET }Performance/PERF_2.pql:package Performance #[Description("Avoid expensive map bracket insertion"), Id(PERF_2), Lang(C++), Category("Performance")] rule PERF_2 = { std.defects.EXPENSIVE_MAP_INSERT_OR_ASSIGN }
Define Sections
In each folder, create a .pql file that groups the rules into a section.
Memory/Memory.pql:package Memory #[Description("Memory Safety")] section Memory = { MEM_1, MEM_2 }ClassDesign/ClassDesign.pql:package ClassDesign #[Description("Class Design")] section ClassDesign = { CLASS_1, CLASS_2 }Performance/Performance.pql:package Performance #[Description("Performance")] section Performance = { PERF_1, PERF_2 }
Assemble Coding Standard
In main.pql, declare a catalog that references all sections using dot notation (<packageName.sectionName>):
package main
#[Categories("Safety", "Design", "Performance")]
catalog ProjectSafety = {
Memory.Memory,
ClassDesign.ClassDesign,
Performance.Performance
}Categories attribute specifies the priority ordering of categories. Categories listed first have higher priority.Package Coding Standard
To produce the .pschk file, navigate to the ProjectSafety folder and run:
polyspace-query-language packageProjectSafety.pschk. Share this file with your team.Test Coding Standard
Before deploying the coding standard, verify that it reports violations on known noncompliant code. Create a C++ file that contains violations for some of the rules in your standard. For example, create a file test_src.cpp containing code that violates the CLASS_1 rule (a non-const member function that does not access data members).
Run the test:
polyspace-query-language test test_src.cpp//expect- comments in the source file to mark expected violations. For example, the following comment indicates that the line is expected to show 1 violation of the check
CLASS_1:class Rect {
double w, h;
public:
double area() { return w * h; } //expect-1-CLASS_1
void setW(double nw) { w = nw; }
};Use Coding Standard in Analysis
To check for violations of the coding standard, use one of these methods:
Command line — Specify the
.pschkfile as input to the optionCheckers activation file (-checkers-activation-file):polyspace-bug-finder -checkers-activation-file ProjectSafety.pschk -sources mysource.cppPolyspace Platform user interface — In the Configuration pane, select Static Analysis > Defects and Coding Standards. Enter the
.pschkfile in the Checkers activation file box.Polyspace as You Code™ — Specify the
.pschkfile in the Checkers Selection window.
For more information, see Check for Violations of User-Defined Coding Standard Using Polyspace Bug Finder.
Summary of Folder Structure
The complete folder structure for the ProjectSafety standard is as follows:
ProjectSafety/
├── main.pql
├── Memory/
│ ├── Memory.pql
│ ├── MEM_1.pql
│ └── MEM_2.pql
├── ClassDesign/
│ ├── ClassDesign.pql
│ ├── CLASS_1.pql
│ └── CLASS_2.pql
└── Performance/
├── Performance.pql
├── PERF_1.pql
└── PERF_2.pqlFor more information on structuring your coding standard files, see Best Practices for Creating User-Defined Coding Standards.