SonarLint 2.0 Is Now Available

SonarLint is a pretty recent product that we released for the first time a few months ago for Eclipse, IntelliJ and Visual Studio. We have recently released the version 2.0 which brings the ability to connect SonarLint with a SonarQube server and was greatly expected by the community. I think the addition of this new feature is a good chance to recap SonarLint features. But before I do this, let me remind you of the SonarLint’s mission: to help developers spot as many coding issues as possible in their IDE, while they code. It has to be instant, integrated to the IDE, and valuable.

Read the rest of this page »

SonarQube 5.5 in Screenshots

The team is proud to announce the release of 5.5, which features simplified concepts for easier triage and management of issues:

  • New SonarQube Quality Model
  • New Measures project page
  • Increased vertical scalability, performance, and stability

Read the rest of this page »

What’s New in SonarEcosystem – April 2016

Read the rest of this page »

SonarSource City Tour, We Are Coming Near You

Since we love touring and meeting our community of users, we’re setting out on the road once again, this time to more cities than ever! Over the next 6 months you’ll be able to see us and ask any questions you have, in more than 10 cities in Europe and the US.

Read the rest of this page »

SonarAnalyzer for Java: Tricky Bugs are Running Scared

For the past year, the SonarSource team behind the SonarAnalyzer for Java has invested most of its time in developing a Symbolic Execution engine in order to find the kind of tricky bugs that are almost uncatchable by developers unaided.

The SonarAnalyzer for Java’s new symbolic execution engine allows it to statically trace all the execution paths in a piece of code. We’ll probably do a blog post in the near future to explain all the related concepts: Program Point, Program State, Symbolic Value, Control Flow Graph, Stack of Symbolic Values, Constraints on Symbolic Values, … but for the time being let’s just see the engine in action.

Read the rest of this page »

Stop planning; fix the leak!

So there you are: you’ve finally decided to install the SonarQube platform and run a couple of analyses on your projects, but it unveiled so many issues that your team doesn’t know where to start. Don’t be tempted to start fixing issues here and there! It could be an endless effort, and you would quickly be depressed by the amount of work that remains. Instead, the first thing you should do is make sure your development team fixes the leak. Apply this principle from the very beginning, and it will ensure that your code is progressively cleaned up as you update and refactor over time. This new paradigm is so efficient at managing code quality that it just makes the traditional “remediation plan” approach obsolete. Actually, so obsolete that related features will disappear in SonarQube 5.5: action plans and the ability to link an issue to a third party task management system.

Read the rest of this page »

SonarQube 5.4 in Screenshots

The team is proud to announce the release of 5.4, a more usable and informative version than ever before:

  • New “My Account” space to collect all your data in once place
  • “Execute Analysis” permission can now be granted at the project level
  • OAuth2 support
  • New “Code” page to list and search for the files in your project
  • Server restart from the UI
  • JavaScript and C# plugins embedded by default
  • Cross-module duplication is back!

Read the rest of this page »

ECMAScript 2015: With Great Power Comes Great Responsibility

Last summer a revolutionary version of ECMAScript was released with native classes, modules, arrow functions and many other long-awaited features.

Accordingly, the latest release of the Sonarqube JavaScript plugin has a bunch of new rules targeting ES2015 syntax. With our new rules we try to enforce some conventions which have already become the standard in JavaScript world.

Let’s go through some of them.

Read the rest of this page »

Why You Shouldn’t Use Build Breaker

There have been some heated discussions recently about the Build Breaker plugin… SonarSource doesn’t want to continue the feature. The community has come to see it as a must have… So I’d like to explain why at SonarSource we no longer think it should be used.

Read the rest of this page »

SonarLint for Visual Studio: Let’s Fix Some Real Issues in Code!

As part of the development process of SonarLint for Visual Studio we regularly check a couple of open source projects, such as Roslyn, to filter out false positives and to validate our rule implementations. In this post we’ll highlight a couple of issues found recently in Roslyn project.

Short-circuit logic should be used to prevent null pointer dereferences in conditionals (S1697)

This rule recognizes a few very specific patterns in your code. We don’t expect any false positives from it, so whenever it reports an issue, we know that it found a bug. Check it out for yourself; here is the link to the problem line.

When body is null, the second part of the condition will be evaluated and throw a NullReferenceException. You might think that the body of a method can’t be null, but even in syntactically correct code it is possible. For example method declarations in interfaces, abstract or partial methods, and expression bodied methods or properties all have null bodies. So why hasn’t this bug shown up yet? This code is only called in one place, on a method declaration with a body.

The ternary operator should not return the same value regardless of the condition (S2758)

We’re not sure if this issue is a bug or just the result of some refactoring, but it is certainly confusing. Why would you check isStartToken if you don’t care about its content?

 “IDisposables” should be disposed (S2930)

Lately we’ve spent some effort on removing false positives from this rule. For example, we’re not reporting on MemoryStream uses anymore, even though it is an IDisposable. SonarLint only reports on resources that should really be closed, which gives us high confidence in this rule. Three issues ([1], [2][3]) are found on the Roslyn project, where a FileStream, a TcpClient, and a TcpListener are not being disposed.

Method overloads with default parameter values should not overlap (S3427)

Mixing method overloads and default parameter values can result in cases when the default parameter value can’t be used at all, or can only be used in conjunction with named arguments. These three cases ([1], [2], [3]) fall into the former category, the default parameter values can’t be used at all, so it is perfectly safe to remove them. In each case, whenever only the first two arguments are supplied, another constructor will be called. Additionally, in this special case, if you call the method like IsEquivalentTo(node: myNode), then the default parameter value is used, but if you use IsEquivalentTo(myNode), then another overload is being called. Confusing, isn’t it?

Flags enumerations should explicitly initialize all their members (S2345)

It is good practice to explicitly set a value for your [Flags] enums. It’s not strictly necessary, and your code might function correctly without it, but still, it’s better safe than sorry. If the enum has only three members, then the automatic 0, 1, 2 field initialization works correctly, but when you have more members, you most probably don’t want to use the default values. For example here FromReferencedAssembly == FromSourceModule | FromAddedModule. Is this the desired setup? If so, why not add it explicitly to avoid confusion?

“async” methods should not return “void” (S3168)

As you probably know, async void methods should only be used in a very limited number of scenarios. The reason for this is that you can’t await on async void method calls. Basically, these are fire and forget methods, such as event handlers. So what happens when a test method is marked async void? Well, it depends. It depends on your test execution framework. For example NUnit 2.6.3 handles them correctly, but the newer NUnit 3.0 dropped support. Roslyn uses xUnit 2.1.0 at the moment, which does support running async void test methods, so there is no real issue with them right now. But changing the return value to Task would probably be advisable. To sum up, double check your async void methods; they might or might not work as you expect. Here are two occurrences from Roslyn ([1], [2]).

Additionally, here are some other confusing pieces of code that are marked by SonarLint. Rule S2275 (Format strings should be passed the correct number of arguments) triggers on this call, where the formatting arguments 10 and 100 are not used, because there are no placeholders for them in the format string. Finally, here are three cases ([1], [2], [3]) where values are bitwise OR-ed (|) with 0 (Rule S2437).

We sincerely hope you already use SonarLint daily to catch issues early. If not, you can download SonarLint from the Visual Studio Extension Gallery or install it directly from Visual Studio (Tools/Extensions and Updates). SonarLint is free and already trusted by thousands of developers, so start using it today!

Page 1 of 2712345678910...20...Last »

© 2008-2015, SonarSource S.A, Switzerland. All content is copyright protected. SONARQUBE and SONARSOURCE are
trademarks of SonarSource SA. All other trademarks and copyrights are the property of their respective owners. All rights are expressly reserved.