ifdef::env-github[]
:tip-caption: :bulb:
:note-caption: :information_source:
endif::[]
= Rule Metadata

This document describes how `+metadata.json+` should be structured.

== `title`, `type`, `tags`, `remediation`, and `defaultSeverity`

These fields are described in the https://docs.sonarqube.org/latest/extension-guide/adding-coding-rules/#coding-rule-guidelines[SonarQube documentation].

== `quickfix` field

Every active rule that is not a security hotspot must specify the availability of a quick fix for its issues.
`metadata.json` must feature a `quickfix` field with one of the following values:

* `unknown`: the feasibility of producing a quick fix is not evaluated.
* `infeasible`: it is not feasible to propose a quick fix for any of the issues, for whatever reason.
* `targeted`: it is possible to implement quick fixes for this rule, but none are implemented right now.
* `partial`: some of the issues produced by the rule propose a quick fix, but not all.
* `covered`: all the issues produced by the rule propose a quick fix.

[NOTE]
====
A `covered` rule is still not guaranteed to provide a quick fix for a particular issue (for instance, if a fix location would be inside a macro expansion or in a different file from the issue location). The rule is said to have a `partial` quick fix only if there exists a family of issues that cannot have a quick fix.

For instance, on one hand, if a rule detects two functions that are dangerous to use, `A` and `B`, and `A` has an obvious replacement (and therefore a quick fix) while `B` does not, the field should be set to `partial`.

On the other hand, if a quick fix could be easily proposed for both `A` and `B`, but the fix location might be inside a macro expansion, or in a different file from the issue location (and hence not feasible given the current SonarLint capabilities), this should not prevent the rule from being tagged as `covered`.
====

[TIP]
====
You can update the quickfix field using this GitHub Workflow: https://github.com/SonarSource/rspec/actions/workflows/update_quickfix_status.yml
====


== `code` field

The code field is an object that contains information related to the clean code taxonomy. It is an object with two required properties:

* `impacts`: A nested object that is treated as a mapping from a software quality to a level (`"INFO"`, `"LOW"`, `"MEDIUM"`, `"HIGH"` or `"BLOCKER"`). Note that at least one software quality has to be specified. The current list of allowed software qualities is `"MAINTAINABILITY"`, `"RELIABILITY"` and `"SECURITY"`.

* `attribute`: A single clean code attribute that the rule aims to achieve. This has to be one of the following values: `"FORMATTED"`, `"CONVENTIONAL"`, `"IDENTIFIABLE"`, `"CLEAR"`, `"LOGICAL"`, `"COMPLETE"`, `"EFFICIENT"`, `"FOCUSED"`, `"DISTINCT"`, `"MODULAR"`, `"TESTED"`, `"LAWFUL"`, `"TRUSTWORTHY"`, `"RESPECTFUL"`.