Skip to content

Open Source

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

Sonar - Wed, 02/10/2016 - 10:38

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!

Categories: Open Source

How to correctly fill in a Story?

IceScrum - Tue, 02/09/2016 - 11:27
Hello everybody and welcome to this first blog post of 2016! In this article I am going to present you quite a simple topic, which is nevertheless mandatory to make your Scrum project a success: “How to correctly fill in your stories?”. Story fields First, let’s review their fields in their order of appearance. Name…
Categories: Open Source

SonarQube 5.3 in Screenshots

Sonar - Thu, 01/28/2016 - 10:02

The team is proud to announce the release of 5.3, another paradigm-shifting version, with the addition of significant new features, and the return of popular functionality that didn’t make it in to 5.2:

  • New Project Space which puts the focus on the Quality Gate and the Leak Period
  • User tokens for authenticated analysis without passwords
  • New web services to facilitate a build breaker strategy
  • Cross-project duplication is back!

New Project Space which puts the focus on the Quality Gate and the Leak Period

The most striking change in this version is the replacement of the default project dashboard with a new, fixed Project space highlighting the top four data domains: technical debt, coverage, duplications, and structure (which includes both size and complexity):

Because managing technical debt introduced during the Leak Period is so crucial, this streamlined, new project home page keeps the leak period (first differential period, which is now overridable at the project level), in the forefront. Both current and differential values are shown both textually and graphically:

Each of the four domains offers a detailed sub-page, available either through the “more” links on the Project Space or the relevant project menu items:

Technical Debt:

Each domain page offers the same combination of current values (in blue, with clickthroughs) and leak period changes (yellow background) found on the main page, along with detailed numeric and graphical presentations designed to help you quickly zero-in on the worst offenders in your projects.

SonarSource feels so strongly about the value of the new Project Space and the domain pages that none of them are configurable. But your old dashboards are still available under the “Dashboards” menu item.

User tokens for authenticated analysis without passwords

In version 5.2, we cut the last ties between analysis and the database. Now an analysis report is submitted to the server and all database updates take place server-side. In 5.3 we take the next step down the road of enhanced analysis security with the introduction of authentication tokens.

Now an administrator can create authentication tokens for any user.

Tokens may be used in for analysis and with web services. Simply pass the token as the login, and leave the password blank.

The list of user token names (but not values!) is easily visible, and existing tokens can be revoked at any time:

Users can’t generate their own tokens yet, but that’s coming soon.

New web services to facilitate a build breaker strategy

In the implementation of a Continuous Inspection strategy, many people use Continuous Integration servers, such as Jenkins, to execute their SonarQube scans, and want to show as broken a run that includes new code that breaks fails the Quality Gate. Because of time constraints, the old hooks for that were removed in 5.2 and not replaced. In 5.3. we made it a priority to close this gap, so the functionality is now available to allow you to implement a build breaker strategy.

When the client-side scanner is done, it writes out a data file with the URL to call for the server-side processing status

Once the processing is successful,

you can use the analysis id to get the quality gate status

Cross-project duplication is back!

Also under the heading of returning favorites is cross-project duplication. The changes in 5.2 required serious API updates. In turn a rewrite of cross-project duplication detection was required – another priority in 5.3

Notably, 5.3 only provides cross-project duplication detection, not the detection of duplications across modules within a project, which is planned for 5.4.

That’s All, Folks!

Time now to download the new version and try it out. But don’t forget to read the installation or upgrade guide first!

Categories: Open Source

Don’t Cross the Beams: Avoiding Interference Between Horizontal and Vertical Refactorings

JUnit Max - Kent Beck - Tue, 09/20/2011 - 03:32

As many of my pair programming partners could tell you, I have the annoying habit of saying “Stop thinking” during refactoring. I’ve always known this isn’t exactly what I meant, because I can’t mean it literally, but I’ve never had a better explanation of what I meant until now. So, apologies y’all, here’s what I wished I had said.

One of the challenges of refactoring is succession–how to slice the work of a refactoring into safe steps and how to order those steps. The two factors complicating succession in refactoring are efficiency and uncertainty. Working in safe steps it’s imperative to take those steps as quickly as possible to achieve overall efficiency. At the same time, refactorings are frequently uncertain–”I think I can move this field over there, but I’m not sure”–and going down a dead-end at high speed is not actually efficient.

Inexperienced responsive designers can get in a state where they try to move quickly on refactorings that are unlikely to work out, get burned, then move slowly and cautiously on refactorings that are sure to pay off. Sometimes they will make real progress, but go try a risky refactoring before reaching a stable-but-incomplete state. Thinking of refactorings as horizontal and vertical is a heuristic for turning this situation around–eliminating risk quickly and exploiting proven opportunities efficiently.

The other day I was in the middle of a big refactoring when I recognized the difference between horizontal and vertical refactorings and realized that the code we were working on would make a good example (good examples are by far the hardest part of explaining design). The code in question selected a subset of menu items for inclusion in a user interface. The original code was ten if statements in a row. Some of the conditions were similar, but none were identical. Our first step was to extract 10 Choice objects, each of which had an isValid method and a widget method.


if (...choice 1 valid...) {
if (...choice 2 valid...) {


$choices = array(new Choice1(), new Choice2(), ...);
foreach ($choices as $each)
  if ($each->isValid())

After we had done this, we noticed that the isValid methods had feature envy. Each of them extracted data from an A and a B and used that data to determine whether the choice would be added.

Choice pulls data from A and B

Choice1 isValid() {
  $data1 = $this->a->data1;
  $data2 = $this->a->data2;
  $data3 = $this->a->b->data3;
  $data4 = $this->a->b->data4;
  return ...some expression of data1-4...;

We wanted to move the logic to the data.

Choice calls A which calls B

Choice1 isValid() {
  return $this->a->isChoice1Valid();
A isChoice1Valid() {
  return ...some expression of data1-2 && $this-b->isChoice1Valid();

Which Choice should we work on first? Should we move logic to A first and then B, or B first and then A? How much do we work on one Choice before moving to the next? What about other refactoring opportunities we see as we go along? These are the kinds of succession questions that make refactoring an art.

Since we only suspected that it would be possible to move the isValid methods to A, it didn’t matter much which Choice we started with. The first question to answer was, “Can we move logic to A?” We picked Choice. The refactoring worked, so we had code that looked like:

Choice calls A which gets data from B

A isChoice1Valid() {
  $data3 = $this->b->data3;
  $data4 = $this->b->data4;
  return ...some expression of data1-4...;

Again we had a succession decision. Do we move part of the logic along to B or do we go on to the next Choice? I pushed for a change of direction, to go on to the next Choice. I had a couple of reasons:

  • The code was already clearly cleaner and I wanted to realize that value if possible by refactoring all of the Choices.
  • One of the other Choices might still be a problem, and the further we went with our current line of refactoring, the more time we would waste if we hit a dead end and had to backtrack.

The first refactoring (move a method to A) is a vertical refactoring. I think of it as moving a method or field up or down the call stack, hence the “vertical” tag. The phase of refactoring where we repeat our success with a bunch of siblings is horizontal, by contrast, because there is no clear ordering between, in our case, the different Choices.

Because we knew that moving the method into A could work, while we were refactoring the other Choices we paid attention to optimization. We tried to come up with creative ways to accomplish the same refactoring safely, but with fewer steps by composing various smaller refactorings in different ways. By putting our heads down and getting through the other nine Choices, we got them done quickly and validated that none of them contained hidden complexities that would invalidate our plan.

Doing the same thing ten times in a row is boring. Half way through my partner started getting good ideas about how to move some of the functionality to B. That’s when I told him to stop thinking. I don’t actually want him to stop thinking, I just wanted him to stay focused on what we were doing. There’s no sense pounding a piton in half way then stopping because you see where you want to pound the next one in.

As it turned out, by the time we were done moving logic to A, we were tired enough that resting was our most productive activity. However, we had code in a consistent state (all the implementations of isValid simply delegated to A) and we knew exactly what we wanted to do next.


Not all refactorings require horizontal phases. If you have one big ugly method, you create a Method Object for it, and break the method into tidy shiny pieces, you may be working vertically the whole time. However, when you have multiple callers to refactor or multiple implementors to refactor, it’s time to begin paying attention to going back and forth between vertical and horizontal, keeping the two separate, and staying aware of how deep to push the vertical refactorings.

Keeping an index card next to my computer helps me stay focused. When I see the opportunity for a vertical refactoring in the midst of a horizontal phase (or vice versa) I jot the idea down on the card and get back to what I was doing. This allows me to efficiently finish one job before moving onto the next, while at the same time not losing any good ideas. At its best, this process feels like meditation, where you stay aware of your breath and don’t get caught in the spiral of your own thoughts.

Categories: Open Source

My Ideal Job Description

JUnit Max - Kent Beck - Mon, 08/29/2011 - 21:30

September 2014

To Whom It May Concern,

I am writing this letter of recommendation on behalf of Kent Beck. He has been here for three years in a complicated role and we have been satisfied with his performance, so I will take a moment to describe what he has done and what he has done for us.

The basic constraint we faced three years ago was that exploding business opportunities demanded more engineering capacity than we could easily provide through hiring. We brought Kent on board with the premise that he would help our existing and new engineers be more effective as a team. He has enhanced our ability to grow and prosper while hiring at a sane pace.

Kent began by working on product features. This established credibility with the engineers and gave him a solid understanding of our codebase. He wasn’t able to work independently on our most complicated code, but he found small features that contributed and worked with teams on bigger features. He has continued working on features off and on the whole time he has been here.

Over time he shifted much of his programming to tool building. The tools he started have become an integral part of how we work. We also grew comfortable moving him to “hot spot” teams that had performance, reliability, or teamwork problems. He was generally successful at helping these teams get back on track.

At first we weren’t sure about his work-from-home policy. In the end it clearly kept him from getting as much done as he would have had he been on site every day, but it wasn’t an insurmountable problem. He visited HQ frequently enough to maintain key relationships and meet new engineers.

When he asked that research & publication on software design be part of his official duties, we were frankly skeptical. His research has turned into one of the most valuable of his activities. Our engineers have had early access to revolutionary design ideas and design-savvy recruits have been attracted by our public sponsorship of Kent’s blog, video series, and recently-published book. His research also drove much of the tool building I mentioned earlier.

Kent is not always the easiest employee to manage. His short attention span means that sometimes you will need to remind him to finish tasks. If he suddenly stops communicating, he has almost certainly gone down a rat hole and would benefit from a firm reminder to stay connected with the goals of the company. His compensation didn’t really fit into our existing structure, but he was flexible about making that part of the relationship work.

The biggest impact of Kent’s presence has been his personal relationships with individual engineers. Kent has spent thousands of hours pair programming remotely. Engineers he pairs with regularly show a marked improvement in programming skill, engineering intuition, and sometimes interpersonal skills. I am a good example. I came here full of ideas and energy but frustrated that no one would listen to me. From working with Kent I learned leadership skills, patience, and empathy, culminating in my recent promotion to director of development.

I understand Kent’s desire to move on, and I wish him well. If you are building an engineering culture focused on skill, responsibility and accountability, I recommend that you consider him for a position.



I used the above as an exercise to help try to understand the connection between what I would like to do and what others might see as valuable. My needs are:

  • Predictability. After 15 years as a consultant, I am willing to trade some freedom for a more predictable employer and income. I don’t mind (actually I prefer) that the work itself be varied, but the stress of variability has been amplified by having two kids in college at the same time (& for several more years).
  • Belonging. I have really appreciated feeling part of a team for the last eight months & didn’t know how much I missed it as a consultant.
  • Purpose. I’ve been working since I was 18 to improve the work of programmers, but I also crave a larger sense of purpose. I’d like to be able to answer the question, “Improved programming toward what social goal?”
Categories: Open Source

Thu, 01/01/1970 - 02:00