PLSQL-specific features and guidance

Parsing Exclusions

The grammar for PLSQL used in PMD has several bugs and might not parse all DDL scripts without errors. However, it should be best practice to call PMD for every DDL script. Thus, we introduce the following workaround to cope with the situation.

We introduce two special comments PMD-EXCLUDE-BEGIN and PMD-EXCLUDE-END which cause PMD to treat the source in between these comments more or less like a multi-line comment, or in other words, just not try to parse them.

It is good practice to include a reason for excluding inside the -- PMD-EXCUDE-BEGIN comment separated by a colon.

The PMD-EXCLUDE-BEGIN and PMD-EXLUDE-END comment lines must not contain other statements, e.g. do_xy(); -- PMD-EXCLUDE-BEGIN is invalid.

Example:

begin
  do_something();
  -- PMD-EXCLUDE-BEGIN: PMD does not like dbms_lob.trim (clash with TrimExpression)
  dbms_lob.trim(the_blob, 1000);
  -- PMD-EXCLUDE-END
  do_something_else();
end;

The existence of exclusions can be detected with the attributes ExcludedRangesCount and ExcludedLinesCount of the top-level ASTInput node. If nothing is excluded, both values are 0 (zero). Otherwise, ExcludedRangesCount contains the number of excluded line-ranges and ExcludedLinesCount is the total number of excluded lines. A future version of PMD might pass the line excluded line ranges, source fragments and the corresponding reason comments as child nodes of the top-level ASTInput node.

In order to keep track where such parse exclusions are used, you could create a custom XPath rule with the following expression:

/Input[@ExcludedRangesCount > 0]

This will find all files with at least one excluded range.

Tags: languages