Skip to content

Syndicate content
Continuous Code Quality
Updated: 3 hours 56 min ago

SonarCFamily Now Supports ARM Compilers

Thu, 06/15/2017 - 16:08

For those not familiar with ARM (Advanced RISC Machine), let’s start by sharing some numbers: in 2011, the 32-bit ARM architecture was the most widely used architecture in mobile devices and the most popular 32-bit one in embedded systems (see). Moreover in 2013, 10 billion were produced (see) and “ARM-based chips are found in nearly 60 percent of the world’s mobile devices” (see).

Why ARM is so popular when dealing with embedded systems? Because the RISC architecture typically requires fewer transistors than those with a complex instruction set computing (CISC) architecture (such as the x86 processors found in most personal computers), which reduces cost, power consumption, and heat dissipation. These characteristics are desirable for light, portable, battery-powered devices‍—‌including smartphones, laptops and tablet computers, and other embedded systems.

Most developers targeting this ARM architecture, develop in C or C++ and use a compiler able to produce a binary for ARM machines. Both GCC and Clang support an ARM mode out-of-the-box. But if you want to generate a binary finely tuned to reduce the runtime footprint, you might want to go ahead with the ARM5, ARM6 or Linaro compilers.

SonarCFamily code analyzer version 4.8 adds support for all such compilers, this long-awaited feature finally becomes reality.

Analyzing a C/C++ project targeting the ARM architecture is not different than analyzing any other kind of C/C++ project but as a reminder here are the steps to follow:

# on Windows or on Linux, in a ARM DS-5 enabled environment:
make clean
build-wrapper-[win|linux]-x86-64 --out-dir <output directory> make
# set on

or, on Linux, from a console without ARM environment:

/usr/local/DS-5_v5.26.2/bin/suite_exec -t "ARM Compiler 5 (DS-5 built-in)" make clean
build-wrapper-linux-x86-64 --out-dir /usr/local/DS-5_v5.26.2/bin/suite_exec -t "ARM Compiler 5 (DS-5 built-in)" make
# set<output directory> on

Once you have analyzed the ARM compiled source code, you got the full power of the analysis available: hundred of rules available to track the nastiest issues, data-flow analysis included!

Of course, SonarCFamily 4.8 is compatible with SonarLint which means that ARM DS-5 developers using Eclipse or any Eclipse CDT developer will be able to use SonarLint and get their code analyzed on-the-fly. This enables to shorten the development feedback and catch issues “before they exist”!
SonarLint in action on Eclipse ARM DS-5

Categories: Open Source

The Tweets You Missed in May

Fri, 06/09/2017 - 15:22

Here are the tweets you likely missed last month!

SonarJava 4.9 Released: toward the goal to have more than 90% of the bugs being highly relevant, and 4 new rules.

— SonarQube (@SonarQube) May 15, 2017

SonarC# 5.10 Released: 9 new rules and lot of improvements
See example of unconditional jump in Roslyn

— SonarQube (@SonarQube) May 12, 2017

SonarJS 3.0 Released: Being Lean and Mean in JavaScript. Blog Entry: and Product News:

— SonarQube (@SonarQube) May 1, 2017

SonarPython 1.8 Released: to track unused and self-assigned variables.

— SonarQube (@SonarQube) May 22, 2017

SonarLint for IntelliJ 2.10 released: many rules fine-tuned for high accuracy in bug detection and 4 new rules

— SonarLint (@SonarLint) May 30, 2017

SonarLint for Eclipse 3.1 refines the analysis of JavaScript to focus on bugs.

— SonarLint (@SonarLint) May 10, 2017

SonarLint for Visual Studio 2.13 brings 9 additional rules

— SonarLint (@SonarLint) May 8, 2017

Categories: Open Source

Kill the Noise! to Change Gear in our Code Analyzers

Thu, 06/01/2017 - 15:48

Over the past few weeks, you may have noticed that most of our product news about code analyzers contained a mention of a “Kill The Noise!” project. We initiated this project at the beginning of the year to sharpen the detection of issues of type “Bug” on certain code analyzers: SonarJS, SonarC#, SonarJava and SonarCFamily. In simpler words, it means that our objective with this project is to make sure that when a SonarQube users clicks on “Bugs” on a project homepage he will be able to fix real and nasty bugs instead of trying to figure out whether the issues he is looking at are real bugs or not.

That may sound like an obvious and mandatory behavior for code analyzers to be extremely sharp when reporting bugs, but do you actually know any analyzer on the market that has at least 90% accuracy?

Over the past two years, we have developed the technology to do path-sensitive DFA (data flow analysis) on C#, Java, JavaScript, C and C++. This technology allows us to go through all execution paths while symbolically simulating the execution of each statement. With help of those DFA engines, we’re able to spot tricky bugs like this one in the Linux kernel:

And then we realized two things :

  • A lot of our older rules of type “Bug” were not really finding obvious bugs, but were more reinforcing good coding practices that help make the code more robust, and therefore reliable. Here are few examples: Non empty switch cases should end with unconditional break statement or Two branches in a conditional structure should not have the same implementation. Those rules spot some real quality issues but most of the time such implementations were done on purpose, and don’t actually lead to unexpected behavior in production.
  • Some rules combined the detection of bugs and quality issues. That was for instance the case for the rule to detect unconditionally true/false conditions. Sounds strange? Here is the reasoning: when a branch is fully unreachable due to an unconditionally false condition there is no doubt about the fact that it is a bug. But when a (sub)condition is unconditionally true, it might be on purpose just to make the code more self-explanatory: Boom! A rule that finds both bugs and quality issues

So we made an effort of reclassification and split of rules. Obviously we made all this while keeping the hunt for the infamous false-positives.

At the end we are all working at SonarSource towards this ultimate goal to have code analyzers being at least 90% accurate when raising issues of type “Bug” and we are not far from making this dream become a reality. Obviously any feedback on the latest versions of SonarJS, SonarC#, SonarJava and SonarCFamily is highly welcome to help us Kill the Noise!

Categories: Open Source

Accelerate Products Development at SonarSource

Wed, 05/10/2017 - 16:53

We founded SonarSource 8 years ago with a dream to one day provide every developer the ability to measure the code quality of his projects. And we had a motto for this: “Democratize access to code quality tooling”. To make this dream come true we invested all our time and energy into developing the SonarQube platform, hiring a great team and building an open source business model to sustain the company growth and keep our freedom. We have also invested a lot in the relationship with our community; giving a lot and also getting back a lot.

Thanks to this approach, here are some examples of what we were able to deliver in the last few years:

  • on-the-fly Feedback in the IDE with SonarLint
  • analysis of 18 languages
  • deep analysis to cover the reliability and security domains
  • high availability and multi-tenancy of the platform to soon launch

After 8 years of effort, we believe we have built great products along with an awesome 60-person company, a solid business and a great brand. We are very proud of these, but we do not think our dream has come true yet. Why? Because Continuous Code Quality still isn’t a commodity the way SCM, Continuous Integration, and artifacts management are: every developer should benefit from the power of a path-sensitive, context-sensitive data flow analysis engine to detect the nastiest bugs and subtlest security vulnerabilities. should be a no-brainer for anyone who uses, VSTS, Travis CI… In other words, everyone writing code should want to benefit from the best analyzers to make sure each line produced is secure, reliable and maintainable.

To take up this challenge, we have made a choice to partner with Insight Venture Partners, one of the very best VCs in our domain. By leveraging their experience, we strongly believe we will be making our dream come true… way sooner than another 8 years!

Simon, Freddy & Olivier
The SonarSource Founders

Categories: Open Source

The Tweets You Missed in April

Fri, 05/05/2017 - 14:58

Here are the tweets you likely missed last month!

SonarQube 6.3 released: read the news and see in it screenshots!

— SonarQube (@SonarQube) April 12, 2017

SonarCFamily 4.7 Released: 4 new rules and a dataflow engine supporting precise values for integer literals

— SonarQube (@SonarQube) April 12, 2017

SonarCOBOL 3.4 Released: 8 new rules

— SonarQube (@SonarQube) April 13, 2017

SonarLint for IntelliJ 2.9 shows paths across methods calls that lead to an exception

— SonarLint (@SonarLint) April 6, 2017

SonarLint for Eclipse 3.0 detects tricky issues on Java and JavaScript thanks to an extended dataflow analysis

— SonarLint (@SonarLint) April 18, 2017

Categories: Open Source

SonarJS 3.0: Being Lean and Mean in JavaScript

Mon, 05/01/2017 - 12:40

All through 2016 SonarJS has become richer and more powerful thanks to new rules and its new data flow engine, to the point of being able to find pretty interesting stuff like this:


That’s cool, isn’t it? Yet, there’s such a thing as being blinded by coolness and, as Pirelli was fond of saying, power is nothing without control. What good is pointing out a very nasty and hidden bug if you have long since stopped listening to what SonarJS has to tell you?

There are two main reasons a developer stops listening to the analyzer:

  1. The analyzer is noisy, stacking issue on top of issue because you insist on having more than one statement per line.
  2. The analyzer says something that is really dumb, so, the developer presumes, the analyzer is dumb. Life is too short to listen to dumb tools.

Unless we tackled both these points we risked having our oh-so-powerful analyzer be perceived like a “the end is nigh” lunatic.


Kill the noise

We don’t want to spam the developer with potentially true but ultimately irrelevant messages. But what is relevant?

We do want to provide value out of the box, so all SonarSource analysers provide a default rule-set, called the “Sonar way” profile, that does represent what it means for us to write good <insert language here> code. This means that we don’t have the luxury of saying “the users will setup the profile with the rules they prefer”, we have to take a stance on which rules are activated by default.

Guess what? Nobody knew that defining what is good JavaScript could be so complicated!

We thus embarked on a deep review of our default “Sonar way” profile to see if we could indeed find a meaningful, useful, common ground. We knew we needed an external point of view and we were very lucky to find a very knowledgeable and critical one: Alexander Kamushkin.

Alexander worked with us for a month and he did an amazing job, if somewhat painful to us, pointing out which rules provided the most value regardless of team culture and idioms, which could become idiom-neutral with some work, and which were by definition optional conventions.

After the first few rounds of discussion he put everything in what we have come to refer to as “Alexander’s Report”, of which this is a very small excerpt:


Of course this was not the end of it, we kept on refining these findings, prioritizing and adding some more all through the development of SonarJS 3.0 and we have more in the pipe for later on.

We improved dozens of rules, splitted rules to separate the unarguable bug-generating cases from maintenance-related cases, added heuristics to kill false-positives, almost no rule previously part of “Sonar way” was left untouched. We also further evolved the data flow engine itself to make sure it was not making assumptions that might lead rules to be overconfident in reporting an issue.

We now feel that the default profile of SonarJS 3.0 is a carefully trimmed set of high-value/low-noise rules useful in almost any JS development context.

We also created a new profile: “Sonar way Recommended”. This profile includes all the rules found in “Sonar way”, plus rules which we have evolved to be high-value/low-noise for JS developments that mandate high code readability and long-term evolution.

Things we learned The issue is in the eye of the beholder

Take for instance one excellent rule: “Dead stores should be removed”. This rule says that if you set a value to a variable and then you set a new value without ever using the previous one you have probably made a mistake.

let x = 3;
x = 10;
alert(“Value : “ + x);

We can hardly be more confident that something is wrong here, you probably wanted to do something with that “3”. What if you are in the habit of initialising all your number variables to 0, or all your strings to empty string?

function bye(p) {
  let answer = "";
  switch(p) {
    case "HELLO" : answer = "GOODBYE";
    case "HI" : answer = "BYE";
    default : answer = "HASTA LA VISTA BABY";
  return answer;

Do we want to raise a dead-store issue on that first initialisation? If we did we could kind of excuse ourselves by saying that it is indeed a dead-store, but since the developer did that on purpose the analyser is at best perceived as pedantic.

After all when raising issues we are not addressing machines but human beings. We want them to read and care about these issues, we cannot hide behind technical correctness, we must be correct and also try to guess when something is done on purpose and when it is a genuine mistake.

It’s not a bug until it is

Before SonarJS 3.0 every issue we detected which could potentially lead to a bug was classified as a bug.

This was done out of a coherent approach at issue criticality and it does draw a clear distinction between potential mistakes and more readability or maintenance-related code smells.

Still, there’s something very alarming in getting a report saying that your project contains 1.542 bugs.

A classic example of this is NaN. If you don’t expect NaN to be a possible value you can introduce some very nasty bugs, because, let’s not forget that NaN == NaN is false!

Still, nothing might happen, because you are careful in other ways and as such playing with NaNs is at worst suspicious, not a bug.

Also, we found out that, as the analyser improved, many potentially dangerous things could be resolved into being either certainly bugs or certainly not bugs. There’s no need to scream about an undefined variable if we can track its value and only raise an issue when you try to access a property on that undefined variable.

If you can’t analyse it, don’t make assumptions

The data flow analysis engine is pretty good, but it still cannot analyse everything. We learnt that if we cannot follow the whole life of a variable’s value we are better off assuming no knowledge than partial knowledge.

let x;
if(p) x = 2;
if(isPositive(x)) {
  return 10/x;

Should we warn you of a possible NaN? It depends if we were able to resolve the declaration of isPositive and go through its implementation. If we don’t know what happens within isPositive, even if we know that it is possible that x is undefined we can’t be sure that x can be undefined when 10/x is executed. It’s safer, to avoid raising an issue because of our partial understanding, to not presume we know anything about x.

And more

There would be much more to say, but for the time being suffice to know that SonarJS 3.0 inaugurates a focus on minimalistic usefulness, or, as Marko Ramius would say: we have engaged the silent drive.

Categories: Open Source