The Rules Have Changed

by g. ann campbell|

    If you've already taken a look at SonaQube 4.4, the title of this post wasn't any news to you. The new version introduces two major changes to the way SonarQube presents data: the new rules space and the changes to the source viewer.

    If you've been keeping up version to version, you've noticed new styling creeping in to the design. We formed a Web team this year to focus on transforming SonarQube’s interface into something as sexy as the underlying functionality, and the team is starting to hit its stride.



    The new rules space is a reimagining of how to interact with rules. Previously, they were accessed only within the context of their inclusion (or not) in a single profile. Want to know if a given rule is present in multiple profiles? Previously, you had to hunker down because it could take a while.

    Now rules have their own independent presentation, with multi-axis search.



    All the search criteria from the old interface are still available, and several new ones have been added. The rule tags introduced in SonarQube 4.2 become searchable in 4.4, as do SQALE characteristics. And for most criteria you can search for multiple values. For example, it's now easy to find rules in both "MyFirstProfile" and "MySecondProfile" simply by checking them both off in the profile dropdown.

    Conversely, if you want to see all the profiles that include the rule "Unused method parameters should be removed", simply pull it up in the search.



    At the bottom of the rule listing, you'll see all the profiles it's included in, along with the severity and any parameters for the profile. If you're an administrator, you'll have controls here to change a rule in its current profiles and to add it to new profiles. The search results pane on the left also features bulk change operations for administrators, allowing them to toggle activation in a profile for all the rules in the search results.

    It's also easy now to find clone-able rules such as XPath and Architectural Constraint in Java; they're called "templates" starting in 4.4, and they get their own search criterion.

    I shouldn't forget to mention the second tier below the search criteria. It represents the categories the search results span: languages, repositories, and tags, and the search results can be further filtered by clicking on the entries there. (A second click deselects and unfilters). For instance, here's the default search filtered to show C rules that have been tagged for MISRA C++:



    The point of this radical overhaul is to give you, the user, a better way to explore rules; to see what rules are available, which rules are used where, and which rules you might want to turn on or ask your administrator to turn on.

    One interesting aspect of this is the new ability to explore rule activation across languages. For rules that are implemented directly within a plugin, as opposed to coming from 3rd party tools like FxCop or FindBugs, you'll see that when the same rule is implemented in multiple languages, it usually has the same key (there are a few historical exceptions.)



    So, for example, now you can easily see whether the same standards are being enforced across all languages in your organization.

    The new rules space is just one piece of our new attitude toward data. Next time I'll talk about the complete rework of the component viewer. It's a reimagining that's just as radical as this one.