Actual results for mediawiki core: https://insight.sensiolabs.com/projects/8b5d527f-f70c-4fc0-977f-de99743eae06/analyses/16
Over all I think making stuff more testable with phpunit is much more important than going through any parts of that report. On 2014-10-23 17:16, Jeroen De Dauw wrote: >> It's probably a useless statistic > > It's based on SensioLabsInsight, which I personally quite dislike. > ScrutinizerCI is hands down better at spotting issues (way to many false > positives on SensioLabsInsight). I think PHP_CodeSniffer (possibly with a few new sniffs) can replace all of their tests. There are many important metrics they do not consider at all. Something quite better than what they have can be obtained with the following tools: phpunit (code coverage), phpcpd (copied code), warnings from your documentation generator like phpdox, PHP_Depend, phploc, PHPMD, PHP_CodeSniffer. See http://jenkins-php.org for how to integrate that into our CI infrastructure. Yes, many false positives. Many of their tests are only of the type: search for where $function is called. In fact I think none of their tests can be classified as static analysis (not sure about "Database queries should use parameter binding", though). Many of their tests can only be used as hints because there are enough instances where that is exactly what one needs to do. Examples: - exit() and die() functions should be avoided - PHP configuration should not be changed dynamically Some more examples that might be useful in some form: - Global variable or function should never be used (This is probably the only really useful one, because removing global functions/variables would result in better testable code.) - PHP debug statements found - Logical operators should be avoided - sleep() should not be used - Source code should not contain FIXME comments -- Regards, Jan Zerebecki _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
