A finding is what a run returns when a rule has something to report. It is not a score and not a style opinion: it names the rule, points at the lines, and links the standard the rule comes from, so you can check the reasoning before you change anything.
What a finding is made of
| Part | What it tells you |
|---|---|
| The rule | The name of the rule that reported, as it appears in the standard |
| The standard | Which standard that rule belongs to |
| The explanation | What is wrong here and why the rule exists |
| Present on: | Every line the rule reported, by number |
| The snippet | The offending line as the analyzer read it |
| View standard | A link to that exact rule, at its own anchor |
One finding is one rule, however many lines it touched. When a rule reported on several lines they are listed together, and the count of lines appears beside the number of findings.
The line numbers count the file exactly as the analyzer received it. If you paste a fragment rather than the whole file, the numbers are the fragment's.
Error or warning
| Severity | What it means | What is expected of you |
|---|---|---|
| Error | The rule was broken and the analyzer can prove it from this file | Fix it and run the file again |
| Warning | Something the rule cannot settle on its own | Decide, and say what you decided |
Warnings do not block the analysis. They are the cases where the correct answer depends on something the analyzer cannot see — intent, or a file it never opened — so a human decision is the point of them rather than an escape from them. Deciding that a warning does not apply here is a valid outcome; leaving it unread is not.
The result you get
| What the panel says | What happened |
|---|---|
| No violations were found. | The code passed the rules that apply to the selected type |
| The code passed, with observations. | It passed, and there are warnings to decide on |
| A list of findings | At least one rule reported, with errors, warnings, or both |
| The analysis finished with general observations. | The run completed without attributing findings to a rule — check the configuration of the applicable rules |
A pass means the code passed the rules that apply to that file type. It is not a statement that the file is good, because a rule that no machine can run cannot report on it. Those four are in What the analyzer cannot check.
What to do with one
Fix the errors first. They are the ones the analyzer proved, and they are cheap: the finding names the line, and the standard behind it shows the correct form.
Read the rule when you disagree. Every rule states why it exists, and that reason is usually the fastest way to tell whether your case is the exception it names or the mistake it describes. Open it from View standard — more on where the rules live in Read the standards.
Run the file again after the fix. A run is closed by a clean run over the changed file, not by the change itself. Both runs stay in The analysis history, so you can compare them.
Report a finding that is wrong. A rule that fires on correct code is a defect in the rule, not something for your project to work around. The same goes for a rule that stayed silent on something it should have caught. Fixing it at the source is what Report a wrong finding covers, and every project gets the corrected rule on its next call.