Skip to content

Checks reference

Every check plc-st-review ships with, what it catches, why it exists, how to configure it, an ST trigger, what the bot posts, and a suggested fix. See check-limitations.md for what each check deliberately doesn't catch.

Two project-wide settings shape how every check resolves identifiers and which .st files it parses:

  • Case sensitivity — case_sensitive: true|false (default false). Pick the value that matches your toolchain (CODESYS / TwinCAT → false; B&R Automation Studio → true). Drives every identifier comparison and gates IDENTIFIER_CASE_MISMATCH.
  • Parsing limits — parsing.max_file_size_bytes (default 1 MB) and the --max-file-size CLI flag control the per-file source-length cap. 0 disables.

Live demo: every check in this document fires at least once on PR #1, where you can see the exact inline comments the bot posts.

Common settings (apply to every check)

Two knobs work on every check, set in .plc-st-review.yml:

severity_overrides:
  CATEGORY_NAME: error      # raise / lower the severity for this category
disabled_checks:
  - CATEGORY_NAME           # turn the check off entirely

Each per-check page below only lists additional knobs (check-specific config, prefix lists, etc.).

Metric thresholds

The metric-regression checks (COMPLEXITY_INCREASED, NESTING_INCREASED, LOC_SPIKE) read their bands from an optional metrics: block. Omit it and the defaults below apply:

metrics:
  thresholds:
    cyclomatic_complexity:
      warn: 15
      error: 25
    nesting_depth:
      warn: 5
      error: 8
    lines_of_code:      # reserved for the standalone --metrics mode
      warn: 300
      error: 600
    comment_ratio:      # reserved for the standalone --metrics mode
      warn_below: 10
    fan_out:            # reserved for the standalone --metrics mode
      warn: 15
      error: 25

cyclomatic_complexity and nesting_depth drive the two threshold-aware checks today; the rest of the block is accepted now so the config is stable ahead of the standalone metrics mode. LOC_SPIKE has no threshold, it fires on any single-PR growth over 50%.

Diff-based checks

These compare the before and after trees of a PR. Every finding implies a change happened in this PR.

COMPLEXITY_INCREASED, NESTING_INCREASED, and LOC_SPIKE are metric-regression checks: they compare a POU's complexity, nesting depth, and lines of code between revisions and fire when a metric degrades. Their bands live in a metrics: block (see Metric thresholds below). DEAD_POU_INTRODUCED is project-scoped: it needs a whole-repo parse and runs only with --project-scope.

Static integrity checks

These run on the after tree alone and surface bugs that compile but mis-behave. Each one filters out findings already present in the before tree so the check only flags new problems introduced in the PR.

FB-instance checks

These target standard IEC 61131-3 function-block patterns (TON, CTU, R_TRIG, SR/RS, etc.), wiring mistakes that won't trip a normal compiler but produce wrong runtime behavior.

Code-quality and style checks

These are stylistic / hygiene checks. Most ship at info severity and stay off your blocking gate by default; raise them in .plc-st-review.yml once your team agrees on a convention.

Several of the above also appear in the PLCopen Coding Guidelines; the PLCopen preset bumps their severities and turns on the limit-gated ones. They're not PLCopen-exclusive though — they're general checks the engine ships standalone.

Security (IEC 62443) checks

These five checks target IEC 62443 industrial-cybersecurity concerns that are statically inferable from ST source — hard-coded credentials, hard-coded network endpoints, unguarded use of VAR_INPUT in privileged operations, debug pragmas left in production, and persistent storage of secret-named variables.

See the IEC 62443 mapping page for the per-clause cross-reference and suggested severity policy by Security Level.

Using a check in your PR

plc-st-review runs automatically once you've set up the GitLab or GitHub integration (see gitlab-setup.md / github-setup.md). Every check above lands as either an inline comment on the relevant .st line or as part of the summary issue / discussion comment when the affected line falls outside the PR's diff hunks.

To suppress a check for a single repo, add it to disabled_checks in .plc-st-review.yml. To raise or lower its severity, use severity_overrides. See tuning-severities.md for the tuning ramp.

To compose policy across many repos, naming conventions, severity profiles, forbidden symbols, use extends: to pull from shared preset files. See preset-packs.md.