Finding Duplicated Code in PHP reloaded¶

Code duplication is generally considered a bad programming style. While it might be appealing and in certain situations faster to duplicate certain code fragments, it often comes at the cost of increased maintenance efforts like harder to change code. Usually, duplicated code is introduced either by copy/pasting. In large code bases, it could also happen that two developers write similar code without even knowing about it.

In PHP, Copy/Paste Detector so far could be used for detecting code clones. On Scrutinizer, it was enabled by default on all PHP projects. PHP Copy/Paste Detector operates on the token stream which is generated by PHP’s token_get_all function and uses string hashing techniques to find duplicates. This makes it quite good at detecting large literal code duplications. However, often developers modify copy/pasted code slightly which could then not be detected anymore.

To overcome the current shortcomings, we are happy to introduce a new tool for duplicated code detection, PHP Similarity Analyzer. PHP Similarity Analyzer is based on latest academic research combined with our in-depth practical experience. It has been evaluated against a range of open-source and closed-source projects and its results are already very promising. In contrast to PHP Copy/Paste Detector, it is robust against code modification and also finds smaller code fragments which make very good targets for refactoring. Besides, it not only detects copy/pasted code, but also semantically similar code.

You can enable PHP Similarity Analyzer on your repository with the following configuration:

tools:
    php_sim: true

    # PHP Similarity Analyzer and Copy/paste Detector cannot be used at
    # the same time right now. Make sure to either remove, or disable one.
    php_cpd: false

Check it out, and let us know what you think.

Happy inspecting :)

Introducing Build Failure Conditions¶

By default, Scrutinizer has no notion of whether the build for a specific commit failed or passed, it simply delegates that decision to your continuous integration service which after all runs your tests.

However, many people have voiced the desire to have builds fail based on certain conditions. For example, you might want to fail if a critical issue is introduced, a class has no tests, or the rating drops below a certain threshold, just to name a few uses cases.

We just rolled out a new DSL to make these checks possible. The DSL is super-easy to write and read, let’s take a look at a few examples:

# .scrutinizer.yml

build_failure_conditions:
    # No critical issue is present
    - 'issues.severity(= CRITICAL).exists'

    # No new critical issue is introduced (existing ones are tolerated)
    - 'issues.severity(= CRITICAL).new.exists'

    # Class has no tests
    - 'classes.metric("php_code_coverage.coverage", = 0).exists'

    # Rating is D or worse
    - 'elements.rating(<= D).exists'

You can read more about the options this DSL offers in our documentation. If your use-case is not yet covered, let us know.

If one of your failure conditions is true for an inspection, Scrutinizer will set the build to failed and add a prominent note to the summary page.

In case you are using GitHub, the build status will also be set through GitHub’s status API and merged with your continuous integration service.

Happy inspecting! :)

Side-by-Side View for Code Duplication¶

Scrutinizer has already had support for detecting duplications in your source code. Duplicate code is probably one of the most obvious code smells. When detected, the duplicate code was already marked with an orange bar which showed the locations of the duplicated code.

To make it easier to compare the duplicated code, we now also offer a side-by-side view of the files where the duplicated code was found. Let’s take a look:

Surpassing 2500 Repositories¶

I’m happy to announce that there are now more than 2500 active repositories on Scrutinizer. That’s really awesome.

Scrutinizer started as a vague idea more than two years ago and it is nice to see that so many people love and use Scrutinizer today. Your feedback is and has been very valuable throughout this time. We receive lots of positive feedback, but also many feature requests or critiques, and work hard to improve your experience each day.

Keep it coming, and to another 2500 repositories. Cheers! :)

Making Issues even more helpful¶

Recently, we rolled out several updates to improve your experience around issues.

Additional Help and Background Information¶

When crafting an issue message, it is sometimes difficult to strike a balance between providing you with enough information to fix the issue and not producing a big wall of text. Besides when you first encounter an issue, you might need more information than on subsequent encounters.

To help solve this, we have now introduced extended help messages. Extended help messages are already available for quite a few messages for all supported analysis tools. If an issue has such a help message, it is marked with an info icon (see below). The help message usually has some background and suggestions on how to fix the issue: