SonarLint - Bug hunting season is open

What if your IDE could warn you as soon as you wrote bad code? More than just warning, what if it could teach you why something is bad, show you best practices, and give you examples of fixes? I'm not talking about poorly formatted code, or similarly minor issues. Thanks to powerful code analyzers also found in the well-known SonarQube platform, you can expect to catch serious flaws that would have led to critical bugs or security breaches.

Eager to try? Please follow the guide.

Setup

You can find SonarLint in the Eclipse Marketplace. Just install it and voila! Out of the box it will analyze Java, JavaScript, PHP and Python files. You can unlock more features by connecting SonarLint with a SonarQube server, but we'll talk about that later. SonarLint and the embedded analyzers are free and open-source.

Use

To use SonarLint, simply write code as you usually do. Bugs or vulnerabilities will be annotated directly in the editor when you save changes.

A dedicated view lets you browse all the issues detected by SonarLint. It's sorted by date, most recent first, so you can easily spot the one you've just introduced.

If the message is not clear enough to understand an issue, simply open the rule description. We make an extra effort to give you a lot of details so you can learn and make an informed decision (there is not always one absolutely correct way to fix an issue).

How to find (non trivial) bugs with static analysis

As I teased earlier, SonarLint aims to find complex bugs. This is an ongoing effort, and every new version adds more and more checks.
Finding complex bugs requires the best possible understanding of the code. Here is a very approximate description of the process:

• Parsing: to understand the code, the analyzer needs to parse it and build a tree based on a grammar. This is somewhat easy for well-specified languages like Java, but much more difficult for C++, because there are ambiguities.

• Resolving symbols and types: now that we are able to distinguish a keyword from a variable or a method/type definition, it's time to build an index of all symbols with their types/signatures. Again, it may seem obvious in Java when you read ‘int a’ or ‘String s’ that ‘a’ is a primitive integer and ‘s’ is a java.lang.String. But when you add in generics or overloaded methods, it becomes more difficult. And don’t get me started on dynamically typed languages such as JavaScript.
• Data Flow Analysis: this is similar to mentally executing code while reading it, trying to collect as much information as possible on a possible program state. Is this variable initialized? What if this condition is true? Was this resource closed? Data Flow Analysis could, potentially, consume an infinite amount of resources (CPU/Memory) so this is a best-effort approach. The scope of exploration can be limited to a single method/function or extended to be cross-method or even cross-file.

As you probably guessed, simple parsing only enables simple checks. Properly resolving types and Data Flow Analysis is the key that opens the door to very advanced checks, with the potential to reveal serious bugs or vulnerabilities.

Examples

Java

Teaser: this screenshot shows an upcoming feature. SonarLint can highlight the flow leading to some issues. This will become a key feature, since complex Data Flow-based findings may be hard to understand without the context that leads up to them.

JavaScript

C++

Advanced features

You can unlock some additional features by connecting SonarLint to a SonarQube server and then binding your projects. It could be your company's instance, or a cloud instance such as sonarqube.com, which is available for free for open source projects.

Here are some of the benefits of connecting to a SonarQube server:

• Access to all the SonarSource analyzers installed on the server instead of just the default ones. This allows consistent issue reporting and support for additional (including commercial) languages.
• Access to rulesets configured on the server, including custom rules.
• Hide issues marked as "Won't Fix" or "False Positive".

Future

SonarLint evolves quickly. We had 7 releases last year and we'll continue the effort in 2017. Each new version will include updated code analyzers, to spot more and more advanced bugs, but also to improve reporting. Don't hesitate to try it out, and give your feedback on our open discussion list: sonarlint@googlegroups.com. You can report problems, propose new rules, and suggest new features.

Happy bug-hunting!