[Libreoffice-qa] Possibility of monitoring LibreOffice code with SonarQube

[Stephan Bergmann]

On 04/13/2016 09:51 AM, Pasqual Milvaques wrote:
> The coverity scan actually is done with gcov/lcov and is quite useful as
> you say, SonarQube can do code coverage analysis also by importing gcov
> info (http://docs.sonarqube.org/pages/viewpage.action?pageId=5312222) so
> at the end it would present the same data with another gui but it's not
> clear if this could more useful than the current UI.

Coverity Scan is a tool to find programming errors via static analysis. 
  I do not know that it would also address code coverage (which is what 
gcov/lcov do).  (We do have a setup to monitor LO code coverage with 
gcov/locv, too, <https://lcov.libreoffice.org/>.)

> The interesting apportation is that SonarQube can give more information
> about other aspects of the project code quality, all the features are
> summarized here:
> http://www.sonarsource.com/products/features/

 From that web site, SonarQube appears to offer a portfolio of features, 
including some means to find programming errors ("Enfore coding 
standards and eradict bugs"), presumably statically.

There are many tools to statically find programming errors, and we 
already use a variety in LO development: compiler warnings, Clang 
plugins, Coverity Scan, Cppcheck, ...

The problem with any such tool is that it typically reports many errors 
and reports false positives among them.  To be practically useful, the 
rate of errors it reports must be driven to zero (by modifying the LO 
source code, and/or by modifying the tool), to make reports about newly 
introduced errors noticeable.  That means that any false positives must 
be addressed, by either massaging the LO source code or by enhancing the 
tool.

 From my own experience, doing the latter against a closed-source tool 
is a very frustrating experience.  Especially if the tool's provider is 
not very responsive (as has been the case with Coverity in my 
experience).  When there is a false positive for which you do not 
understand why it is reported by the tool, you need to massage the LO 
source code in a trial-and-error way to hopefully make the false warning 
from the tool go away.  (Which easily leaves the LO source code in a 
poorer state than it was in before.)

That is, I'm personally rather reluctant to deploy any further tool to 
find programming errors, when it is unclear whether that tool can be 
used by LO development in a way that helps more than it hurts.