主要内容

Create User-Defined Coding Standard from Existing Checkers

R2026b

If 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:

StandardPQL Name
MISRA C:2012std.misra_c_2012
MISRA C:2023std.misra_c_2023
MISRA C:2025std.misra_c_2025
MISRA C++:2023std.misra_cpp_2023
AUTOSAR C++14std.autosar_cpp14
CERT Cstd.cert
CERT C++std.cert_cpp
CWEstd.cwe_native
Bug Finder defectsstd.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:

SectionRule IDDescriptionBug Finder Checker (PQL Name)
MemoryMEM_1Detect and handle memory allocation errorsstd.cert_cpp.MEM52_CPP
MemoryMEM_2Do not use reallocstd.misra_c_2012.R21_3
Class DesignCLASS_1Make a function a member only if it needs direct access to class representationstd.autosar_cpp14.M9_3_3
Class DesignCLASS_2Make default operations consistentstd.defects.MOVE_OPERATION_USES_COPY, std.autosar_cpp14.A12_8_1, std.autosar_cpp14.A12_1_1
PerformancePERF_1Do not use map when set sufficesstd.defects.EXPENSIVE_USE_OF_MAP_INSTEAD_OF_SET
PerformancePERF_2Avoid expensive map bracket insertionstd.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 init
The init 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 Performance
The folder structure looks like this:
ProjectSafety/
├── 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
}
The 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 package
The command creates ProjectSafety.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
If the test passes, the coding standard reports the expected violations on the noncompliant code and no violations on compliant code. Use //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 .pschk file as input to the option Checkers activation file (-checkers-activation-file):

    polyspace-bug-finder -checkers-activation-file ProjectSafety.pschk -sources mysource.cpp

  • Polyspace Platform user interface — In the Configuration pane, select Static Analysis > Defects and Coding Standards. Enter the .pschk file in the Checkers activation file box.

  • Polyspace as You Code™ — Specify the .pschk file 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.pql

For more information on structuring your coding standard files, see Best Practices for Creating User-Defined Coding Standards.

See Also

Topics