Skip to content

philosophy.md: minor tweaks. add section about usability. [ci skip] #5730

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
danmar merged 1 commit into from
Dec 6, 2023
Merged

philosophy.md: minor tweaks. add section about usability. [ci skip] #5730

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 12 additions & 3 deletions philosophy.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,16 +5,22 @@ It is important that everybody in the Cppcheck team has a consistent idea about

This is a static analyzer tool.

## Usability

Usability is very important. It's more important that Cppcheck is usable than finding all bugs.
- We don't want to have tons of configurations options.
- It's very important that warning messages are well written and with enough details.
- Speed is very important. --check-level=exhaustive can be used when user accept slow analysis.

## Normal analysis - No false positives

A fundamental goal is "no false positives".

It is not possible to achieve "no false positives" completely. One case where false positives are OK is when the code is garbage.

If the code is written as it is by design, then our goal is to not warn.
If the code is written as it is by design, then our goal is to not show any false positives.

If it is not known if there is a problem, then in general we need to bailout. We can only warn when we see that there is a problem.
If it is not known if there is a problem, then in general we need to bailout to avoid false positives. We can only warn when we see that there is a problem.

Stylistic checks are much more prone to false positives and therefore we should avoid writing stylistic checks mostly.

Expand All @@ -24,7 +30,10 @@ Reporting issues in Trac:

### Inconclusive messages

Inconclusive messages will be created if cppcheck cannot be sure there is an issue to warn but 50-50 probability. User shall enable inconclusive messages if they are willing to spend substantially more time on message verification in order to find more issues within a high false positive rate.
If cppcheck can't determine that there is a problem or not, then the analysis is inconclusive.

If the user enables inconclusive warnings and we guess that the probability there is a real problem is at least 50-50 then it's OK to write a inconclusive warning.

Inconclusive messages shall not be used for new checks which are just being developed. There `settings.experimental` can be used.


Expand Down