walkero
/
cppcheck
1
0
Fork 0
Code Issues Pull Requests Projects Releases 1 Wiki Activity

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

This commit is contained in:
Daniel Marjamäki 2023-12-06 11:13:42 +01:00 committed by GitHub
parent 918eca635d
commit 007b5cf8b8
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 12 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
philosophy.md
View File

@ -5,6 +5,12 @@ It is important that everybody in the Cppcheck team has a consistent idea about
This is a static analyzer tool. 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 ## Normal analysis - No false positives
@ -12,9 +18,9 @@ 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. 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. Stylistic checks are much more prone to false positives and therefore we should avoid writing stylistic checks mostly.
@ -24,7 +30,10 @@ Reporting issues in Trac:
### Inconclusive messages ### 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. Inconclusive messages shall not be used for new checks which are just being developed. There `settings.experimental` can be used.