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

Author: danmar

philosophy.md

@@ -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.
 
@@ -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.