Skip to content

Open Source

SonarQube supports ECMAScript 6

Sonar - Tue, 10/28/2014 - 13:53

The 2.1 version of the JavaScript Plugin fully supports ECMAScript 6 (ES6). But what does that mean exactly ?

What is ECMAScript 6 ?

Let’s start from the beginning. The JavaScript language is one implementation of the ECMAScript language standard. (JScript and ActionScript are two more.) Each browser has its own JavaScript interpreter, and most modern browsers support the ECMAScript 5 (ES5) standard. That means that you can write JavaScript that adheres to the ES5 standard and have it work correctly for the vast majority of your users.

ES6 is the next version of the standard, and it provides great new features to allow you to write shareable, efficient, and readable code more easily. Luke Hobbans is a member of TC39, the committee behind ECMAScript. He’s written up a great summary, of the main features of ES6, including a short description of each, complete with code snippet.
Here’s a quick sample for 2 new constructs, variable and constant declaration, and arrow function:

Block scoped binding construct: let for variable declaration and const for constant declaration.

const a = 1;
a = 2;  // error - cannot be re-assigned

if (true) {
  let b = 1;
}
print(b);  // b is undefined

Arrow function: function shorthand using the => syntax.

let sum = (a, b) => a + b;
Can I use ES6 today ?

A new version of the standard also means that each browser needs to provide support for it, at least the major ones. It might take years before it happens, but you don’t have to wait for that to take advantage of the innovations in ECMAScript 6!
Thanks to the availability of ES6-to-ES5 transpilers, it is possible to use ES6 features today. A transpiler will translate your ECMAScript 6 code to ECMAScript 5 code so it can be run by today’s browsers. I like the Traceur compiler, which offers an online demo. You can enter ES6 on the left side and see the resulting ES5 code on right.
AngularJS has already taken advantage of a transpiler to make the move with AngularJS 2.0.

You can follow the progress of ES6 support in browsers and for transpilers in Juriy Zaytsev’s ES6 compatibility matrix.

Use SonarQube to analyze ES6 code

The SonarQube JavaScript Plugin 2.1 fully supports ES6. What does that mean?

It means that the plugin is able to:

  1. parse ES6 source code,
  2. compute all relevant metrics accordingly:
    • a classes count is computed when classes are used
    • class complexity is computed when classes are used
    • the function count includes generator functions
    • general complexity metrics take generators into account
    • the number of accessors is now computed
  3. analyse code against rules, all existing coding rules have been updated to cover the new features, e.g: “unused variable” will detect unused variables & constants declared with let and const.

In upcoming versions, we’ll be adding new rules specific to ES6 features. We’re still figuring out what those should be, but a set of rules about classes is likely. If you’ve got suggestions, please let us know at user@sonar.codehaus.com.

Wanna see a live demo? Check out Angular DI Framework using ES6 on nemo: Angular Dependency Injection v2.

Categories: Open Source

Suggest a Valuable Rule, Win a SonarQubeT-Shirt

Sonar - Wed, 10/08/2014 - 11:58

Is there a rule you’d like to turn on in SonarQube, but you just can’t find it? Well, wish no more, just tweet your missing rule and if its valuable, we’ll implement it.

With coverage of more than 15 languages, developing our own source code analyzers to deliver the most valuable coding rules and bug detection mechanisms is a key mission at SonarSource. In the past, we’ve mainly worked to offer better covererage of rules offered by other rule engines like JSLint, PMD, Toad, CodeSniffer, PHPPMD, CPPCheck, and so on. But the time has come to fly, and now we’d like to know what rules you’re dreaming about.

How to participate

To participate, just tweet the title of your rule and a link to a short description using the tags #1rule1tshirt. If we like it:

  • We’ll add this rule to our Rule Repository, the well from which all new SonarSource rules are drawn.
  • We’ll send you a SonarSource t-shirt.
  • And obviously we’ll do our best to implement this rule and make it available quickly.

That’s it !

Really want few additional details ?
  • The rule can target any language currently covered by SonarSource: Java, C/C++, JavaScript, C#, COBOL, Objective-C, Python, PL/SQL, PHP, ABAP, Android, Flex, Groovy, HTML, PL/I, RPG, VB.Net, XML.
  • You can use whatever’s convenient to host the rule description, such as a Google doc to provide a short description of the rule.
  • The goal of the rule can be either to reinforce a coding practice or to detect some bugs.

Whether or not a rule is valuable is subjective. Like any benevolent dictator, ours will be the final word. :)

Let the tweeting begin!

Categories: Open Source

Analyzing Objective-C: the World of OS X and iOS within your Grasp

Sonar - Thu, 09/25/2014 - 06:50

With version 3.0 of the C / C++ plugin in August, 2014, support of the Objective-C language arrived.

Support of Objective-C in SonarQube was heavily awaited by the community, and has been in our dreams and plans for more than one year. You might wonder – why did it take us so long? And why now, when Apple has announced Swift? Why as a part of the existing plugin? I’ll try to shed light on those questions.

A year ago, there were only two developers in SonarSource’s language team, Dinesh Bolkensteyn and me. We’re both heavy hitters, but with more than a dozen language plugins, we weren’t able to give most of them, including C / C++, as much time as we wanted. Also we had technological troubles with analysis of C / C++. As you may know, source code in C / C++ is hard to parse, because… well, it’s a long story, which deserves a separate blog entry, so just take my word for it, it’s hard. And we didn’t want to provide a quick-win solution by locking ourselves and our users in to third-party tools, which wouldn’t play well in the long-term for the same reasons that third-party tools were a problem in other languages.

Today all that has changed. There are now seven developers on the language team (and room for more), with two dedicated to C / C++. We’ve spent the year not only on the growth of the team, but also on massive improvements to the entire C / C++ technology stack, while preserving its ease of use. At the same time, we’ve delivered eight new releases, with valuable new rules in each release. Since March, we’ve released about once a month, and plan to keep it up.

With solid new technical foundations in place, we were able to dream again about new horizons. One of them was Objective-C. It’s a strict superset of C in terms of syntax, so the work we had done improving the plugin also prepared us to cover Objective-C. Of course, with the announcement of Swift, actually covering Objective-C may not make sense to some, but there’s a lot of Objective-C code already out there, and as history has shown, old programming languages never die.

That’s why we decided to extend the existing plugin to cover Objective-C, and rebrand the plugin “C / C++ / Objective-C”, which is exactly what you see in SonarQube Update Center. Still, to better target the needs of the audiences we decided to have two separated licences: one for C / C++ and one for Objective-C.

And of course this means that out of the box, you get more than 100 Objective-C rules starting straight from the first version, as well as a build-wrapper to simplify analysis configuration. However, during implementation we also realized how unlike C Objective-C is, and for that reason we plan to add new rules targeting specifically Objective-C in the upcoming releases.

So don’t wait any longer, and put your software to the quality analysis!

Categories: Open Source

The Rules Have Changed

Sonar - Wed, 09/10/2014 - 22:34

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.

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.

before:

if (...choice 1 valid...) {
  add($widget1);
}
if (...choice 2 valid...) {
  add($widget2);
}
... 

after:

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

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();
}
Succession

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.

Conclusion

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