Semmle 1.18
Skip to end of metadata
Go to start of metadata

The topics in this space are also available for download as a single PDF file: JAVA-Semmle-1.18.pdf.

About this document

This document was generated automatically from the default dashboard template for Java dashboards from the Semmle 1.18 release, with the addition of rules from the optional advisoryframeworks-javaee, and  jdk9compatibility query suites (marked as optional). 

This release includes no new standard rules. See also Java security rules rules.

See also the security rules for Java analysis: Java Security.


Different industries use a variety of terms to describe mistakes in coding, issues found by software users/testers and potential improvements. Throughout this document, we use the following terms to discuss software quality:
  • RuleA definition of coding errors, bad coding practice or other opportunities to improve the quality of a project. Rules are grouped by category (see table).
  • Query—A request for information—written in QL (the Semmle query language)—used to extract a data set from a database. Rules are implemented using QL queries.
  • Alert/Violation—Code that fails a rule. The meaning of each alert and the best course of action to take varies according to the category of rule that was broken.
  • QL—The query language created by Semmle to facilitate efficient querying of hierarchical data. All rules and metrics are defined by QL queries.

The QL queries that define the rules and metrics described in Semmle standards are distributed as part of Semmle analysis. You can create copies of standard queries and customize them so that they match your internal rules of best coding practice. See Introduction to QL for an introduction to the QL language and Learning QL for an overview of the resources for learning to write your own queries.

Categories of rule

The coding rules are grouped into the following main categories:
CategoryDetectsTypical cost of addressingBenefits of fixing violations of these rules
Correctness Coding mistakesLow, local changes onlyImmediate reduction in risk of software defects
ReadabilityCorrect but confusing syntax or namingLow, local changes onlyImmediate reduction in risk of introducing new defects in future changes to the code
Maintainability Opportunities for structural improvementHigh, refactoring normally required

For frequently updated code, substantial cost/time saving for future changes

For infrequently updated or machine generated code, little benefit

FrameworksFramework-specific issuesLow, typically local changesTypically, immediate reduction in risk of software defects
MetricsTrends in code quality--

Excluding the main categories, all other topics are organized in alphabetic order and consequently the order does not imply any level of priority.

Summary of rules and metrics