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.
_______________________________________________
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: https://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Reply via email to