SonarQube in Action

By Patroklos Papapetrou

Summary

SonarQube in Action shows developers how to use the SonarQube platform to help them continuously improve their source code. The book presents SonarQube's core Seven Axes of Quality: design/architecture, duplications, comments, unit tests, complexity, potential bugs, and coding rules. You'll find simple, easy-to-follow discussion and examples as you learn to integrate SonarQube into your development process.

About the Technology

SonarQube is a powerful open source tool for continuous inspection, a process that makes code quality analysis and reporting an integral part of the development lifecycle. Its unique dashboards, rule-based defect analysis, and tight build integration result in improved code quality without disruption to developer workflow. It supports many languages, including Java, C, C++, C#, PHP, and JavaScript.

About the Book

SonarQube in Action teaches you how to effectively use SonarQube following the continuous inspection model. This practical book systematically explores SonarQube's core Seven Axes of Quality (design, duplications, comments, unit tests, complexity, potential bugs, and coding rules). With well-chosen examples, it helps you learn to use SonarQube's review functionality and IDE integration to implement continuous inspection best practices in your own quality management process.

The book's Java-based examples translate easily to other development languages. No prior experience with SonarQube or continuous delivery practice is assumed

Purchase of the print book includes a free eBook in PDF, Kindle, and ePub formats from Manning Publications.

What's Inside

• Gather meaningful quality metrics
• Integrate with Ant, Maven, and Jenkins
• Write your own plugins
• Master the art of continuous inspection

About the Authors

Ann Campbellb and Patroklos Papapetrou are experienced developers and team leaders. Both actively contribute to the SonarQube community.

Table of Contents

PART 1 WHAT THE NUMBERS ARE TELLING YOU
1. An introduction to SonarQube
2. Issues and coding standards
3. Ensuring that your code is doing things right
4. Working with duplicate code
5. Optimizing source code documentation
6. Keeping your source code files elegant
7. Improving your application design
PART 2 SETTLING IN WITH SONARQUBE
8. Planning a strategy and expanding your insight
9. Continuous Inspection with SonarQube
10. Letting SonarQube drive code reviews
11. IDE integration
PART 3 ADMINISTERING AND EXTENDING
12. Security: users, groups, and roles
13. Rule profile administration
14. Making SonarQube fit your needs
15. Managing your projects
16. Writing your own plugins

• Language: English
• Publisher: Manning
• Release date: Oct 30, 2013
• ISBN: 9781638352891

Patroklos Papapetrou

Patroklos P. Papapetrou is a Java architect, an experienced software developer, and an agile team leader. He is also an active SonarQube community member and contributor.

Book preview

Copyright

For online information and ordering of this and other Manning books, please visit www.manning.com. The publisher offers discounts on this book when ordered in quantity. For more information, please contact

      Special Sales Department

      Manning Publications Co.

      20 Baldwin Road

      PO Box 761

      Shelter Island, NY 11964

      Email: 

[e-mail]

©2014 by Manning Publications Co. All rights reserved.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means electronic, mechanical, photocopying, or otherwise, without prior written permission of the publisher.

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in the book, and Manning Publications was aware of a trademark claim, the designations have been printed in initial caps or all caps.

Recognizing the importance of preserving what has been written, it is Manning’s policy to have the books we publish printed on acid-free paper, and we exert our best efforts to that end. Recognizing also our responsibility to conserve the resources of our planet, Manning books are printed on paper that is at least 15 percent recycled and processed without the use of elemental chlorine.

ISBN 9781617290954

Printed in the United States of America

1 2 3 4 5 6 7 8 9 10 – EBM – 18 17 16 15 14 13

Dedication

To the software architects, programmers, testers, project managers, executives, and end users of every piece of software ever written. We hope this book will make your lives easier.

Brief Table of Contents

Copyright

Brief Table of Contents

Table of Contents

Foreword

Preface

Acknowledgments

About this Book

About the Cover Illustration

1. What the numbers are telling you

Chapter 1. An introduction to SonarQube

Chapter 2. Issues and coding standards

Chapter 3. Ensuring that your code is doing things right

Chapter 4. Working with duplicate code

Chapter 5. Optimizing source code documentation

Chapter 6. Keeping your source code files elegant

Chapter 7. Improving your application design

2. Settling in with SonarQube

Chapter 8. Planning a strategy and expanding your insight

Chapter 9. Continuous Inspection with SonarQube

Chapter 10. Letting SonarQube drive code reviews

Chapter 11. IDE integration

3. Administering and extending

Chapter 12. Security: users, groups, and roles

Chapter 13. Rule profile administration

Chapter 14. Making SonarQube fit your needs

Chapter 15. Managing your projects

Chapter 16. Writing your own plugin

Appendix A. Installation and setup

Appendix B. Analysis

Index

List of Figures

List of Tables

List of Listings

Table of Contents

Copyright

Brief Table of Contents

Table of Contents

Foreword

Preface

Acknowledgments

About this Book

About the Cover Illustration

1. What the numbers are telling you

Chapter 1. An introduction to SonarQube

1.1. Why SonarQube

1.1.1. Proven technologies

1.1.2. Multilingual: SonarQube speaks your language

1.2. Running your first analysis

1.2.1. Installation considerations

1.2.2. Analyzing with SonarQube Runner

1.2.3. Analyzing multilanguage projects

1.2.4. Seeing the output: SonarQube’s front page

1.2.5. Drilling in: the dashboard

1.3. Seven Axes of Quality

1.3.1. Potential bugs and coding rules

1.3.2. Tests

1.3.3. Comments and duplications

1.3.4. Architecture and design

1.3.5. Complexity

1.4. The languages SonarQube covers

1.5. Interface conventions

1.5.1. Hierarchy: packages and classes in a metric drilldown

1.5.2. File details

1.5.3. Trend arrows

1.6. Related plugins

1.6.1. Technical debt

1.6.2. Views

1.7. Summary

Chapter 2. Issues and coding standards

2.1. Looking at your issues

2.2. What issues mean, and why they’re potential problems

2.2.1. Bugs

2.2.2. Potential bugs

2.2.3. Indications of (potential) programmer error

2.2.4. Things that may lead to future programmer error

2.2.5. Inefficiencies

2.2.6. Style inconsistencies (future productivity obstacles)

2.3. Where do issues come from?

2.3.1. Picking a rule profile

2.3.2. Viewing profiles and changing the default

2.4. Related plugins

2.4.1. SCM Activity

2.5. Summary

Chapter 3. Ensuring that your code is doing things right

3.1. Knowing how much of your code is doing things right

3.1.1. Understanding unit-test metrics

3.1.2. Getting reports on unit-test coverage metrics

3.2. Explaining metrics on a file level

3.2.1. Hunting source code lines with low coverage

3.2.2. Finding problems in your unit tests

3.3. Configuring your favorite code-coverage tool

3.3.1. Changing the default selection

3.4. Integration testing

3.4.1. Displaying integration testing coverage on the dashboard

3.4.2. Getting IT information in the source code Coverage tab

3.5. Related plugins

3.6. Summary

Chapter 4. Working with duplicate code

4.1. The hidden cost of duplicate code

4.2. Identifying duplications

4.2.1. Finding your first duplication

4.2.2. Finding duplications on a larger scale

4.2.3. SonarQube’s duplication metrics

4.2.4. Drilling in: from the duplications widget to the Duplications tab

4.3. Realizing the impact of code duplication

4.3.1. The DRY principle: minimizing and eliminating duplications

4.3.2. Duplications vs. size and complexity

4.4. Finding duplications across multiple projects

4.4.1. Turning on cross-project duplication detection

4.4.2. Cross-project duplications in source code tab

4.5. Cleaning up your duplications

4.5.1. Introduction to refactoring patterns

4.5.2. Applying patterns to remove code duplication

4.5.3. Time for a new commons library?

4.6. Related plugins

4.7. Summary

Chapter 5. Optimizing source code documentation

5.1. To document or not?

5.2. Even commenting has its own metrics

5.2.1. How SonarQube calculates metrics

5.2.2. What the numbers are telling you

5.3. Identifying undocumented code

5.3.1. Finding files to improve documentation

5.3.2. Viewing the generic tab in the source code viewer

5.4. Simplifying your documentation strategy

5.4.1. Picking a documentation tool

5.4.2. Defining a straightforward process

5.5. Related plugins

5.5.1. Widget Lab

5.5.2. Doxygen

5.6. Summary

Chapter 6. Keeping your source code files elegant

6.1. Keeping complexity low

6.1.1. Hunting those huge files

6.1.2. Complexity: what it looks like and how to fix it

6.2. Lack of Cohesion of Methods: files that do too much

6.2.1. Getting reports about the LCOM metric

6.2.2. Counting responsibilities

6.2.3. Refactoring for fewer responsibilities

6.3. RFC and couplings: classes with too many friends

6.3.1. Response for Class

6.3.2. Couplings

6.4. Summary

Chapter 7. Improving your application design

7.1. Layering your code

7.1.1. Looking at dashboard widgets

7.1.2. Understanding cycles and unwanted dependencies

7.1.3. Moving from project to package level

7.2. Discovering dependencies and eliminating cycles

7.2.1. Navigating the Dependency Structure Matrix

7.2.2. How the DSM works

7.2.3. Identifying cycles

7.2.4. Library management for Mavenites

7.2.5. Browsing the library-dependency tree

7.2.6. Who uses this library

7.3. Defining your architectural rule set

7.4. Summary

2. Settling in with SonarQube

Chapter 8. Planning a strategy and expanding your insight

8.1. Planning your strategy

8.1.1. Picking a metric

8.1.2. Holding your ground

8.1.3. Moving the goal posts

8.1.4. Boy Scout approach: leave the class better than you found it

8.1.5. SonarQube time: worst first

8.1.6. Re-architect

8.1.7. The end game

8.2. History and trending

8.2.1. Time Machine

8.2.2. Events and database cleanup

8.3. Everything’s a component

8.3.1. Project component view

8.3.2. No package history

8.4. Related plugins

8.4.1. Tab Metrics

8.4.2. Widget Lab

8.5. Summary

Chapter 9. Continuous Inspection with SonarQube

9.1. Introducing Continuous Inspection

9.1.1. What and how?

9.1.2. Life before and after Continuous Inspection

9.1.3. The big picture

9.2. Triggering your analysis with CI

9.2.1. Jenkins setup

9.2.2. Other CI systems

9.2.3. Best practices

9.3. Monitoring quality evolution

9.3.1. Exploring differential views in the project dashboard

9.3.2. Differential views in the issues drilldown

9.3.3. Differential views in the source code viewer

9.3.4. Choosing differential periods

9.3.5. The Compare service

9.4. Related plugins

9.4.1. Cutoff

9.4.2. Build Breaker

9.5. Summary

Chapter 10. Letting SonarQube drive code reviews

10.1. Reviewing code in SonarQube

10.1.1. Issues: a starting point

10.1.2. Confirm, comment, and assign: the simplest workflow options

10.1.3. False positives: sometimes SonarQube gets it wrong

10.1.4. Changing severity: not every issue is that bad

10.1.5. Altering the code to make SonarQube turn a blind eye

10.1.6. Viewing the audit trail

10.2. Creating manual issues: when the rules aren’t enough

10.2.1. Why you would want extra issues

10.2.2. Making manual issues

10.3. Tracking issues

10.3.1. Life cycle of an issue

10.3.2. Tracking squashed issues

10.3.3. Searching issues

10.4. Planning your work with SonarQube’s action plans

10.4.1. Why bother with action plans?

10.4.2. Managing action plans

10.4.3. Using action plans

10.4.4. Tracking action plans

10.5. Structuring a code review

10.5.1. Why: talking about code

10.5.2. Who

10.5.3. When

10.5.4. Where

10.5.5. How

10.6. Related plugins

10.6.1. JIRA

10.6.2. Taglist

10.6.3. Widget Lab

10.7. Summary

Chapter 11. IDE integration

11.1. What’s supported

11.1.1. Generic support

11.1.2. Eclipse support

11.2. Setting up Eclipse integration

11.2.1. Installing the plugin

11.2.2. Configuring the server

11.2.3. Project association

11.3. Working your assigned issues

11.3.1. Finding your assigned issues

11.3.2. Finding and fixing the code

11.4. Running a local analysis

11.5. Related plugins

11.5.1. Issues Report

11.6. Summary

3. Administering and extending

Chapter 12. Security: users, groups, and roles

12.1. Creating users and groups

12.1.1. Managing users

12.1.2. Personalization: what users can manage for themselves

12.1.3. Managing groups

12.2. Roles: who can do what

12.2.1. Project Administrator role

12.2.2. User role

12.2.3. Code Viewer role

12.2.4. Best practices for roles

12.3. System administrators

12.4. Related plugins

12.4.1. LDAP

12.4.2. OpenID

12.4.3. Crowd

12.4.4. PAM

12.5. Summary

Chapter 13. Rule profile administration

13.1. Making your own profile: copy and modify

13.1.1. Copy or start from scratch?

13.1.2. Your first profile edits and their quality implications

13.1.3. Adding rules: how to find them and why you’d want to

13.2. Profile inheritance

13.2.1. Establishing inheritance

13.2.2. Managing the relationship

13.3. Rule editing

13.3.1. Customizing individual rules: editing rule parameters

13.3.2. Cookie-cutter rules: the ones you can duplicate

13.3.3. Extend Description: the rest of the story

13.3.4. Notes: profile-specific records on individual rules

13.4. Alerts: knowing when your metrics have crossed the line

13.5. How to track profile changes

13.5.1. Changelog: who did what, when

13.5.2. Profile versions: when changes go into production

13.5.3. Profile comparison

13.6. Administrative miscellany

13.6.1. Project assignment: which project uses which profile

13.6.2. Profile backup and restoration

13.6.3. Permalinks

13.7. Plugins

13.7.1. Switch Off Violations

13.7.2. Widget Lab

13.8. Summary

Chapter 14. Making SonarQube fit your needs

14.1. Exploring filters

14.1.1. Adding a new filter

14.1.2. Customizing the filter view

14.1.3. Advanced filtering

14.1.4. SonarQube’s default filters

14.2. One size doesn’t fit all: managing global dashboards

14.2.1. Creating your first global dashboard

14.2.2. Customizing your dashboards

14.2.3. Defining default global dashboards

14.3. Getting notified by SonarQube

14.3.1. Activating the notification mechanism

14.3.2. Subscribing to event types

14.4. Adjusting global settings

14.4.1. Database cleaner

14.4.2. General

14.4.3. Localization

14.4.4. Server ID

14.5. Housekeeping

14.5.1. Backing up your SonarQube configuration

14.5.2. Working with the update center

14.6. Summary

Chapter 15. Managing your projects

15.1. Working with project dashboards

15.2. Adopting Continuous Inspection more quickly

15.2.1. Assigning quality profiles

15.2.2. Defining your own metrics

15.2.3. Excluding source code from analysis

15.2.4. Understanding versions, snapshots, and events

15.3. Exploring the rest of the project configuration

15.3.1. Changing permissions

15.3.2. Setting project links

15.3.3. Modifying the project key

15.3.4. Deleting projects

15.3.5. Miscellaneous settings

15.4. Summary

Chapter 16. Writing your own plugin

16.1. Understanding SonarQube’s architecture

16.2. Implementing the Redmine plugin

16.2.1. Creating the plugin Maven project

16.2.2. Defining the plugin’s available configuration

16.2.3. Describing the metrics: what you’ll calculate and store

16.2.4. Implementing your analyzer with a sensor

16.2.5. Creating your first widget

16.2.6. Supporting internationalization

16.2.7. A decorator example

16.3. Adding support for new programming languages

16.4. Summary

Appendix A. Installation and setup

A.1. Preparing for installation

A.1.1. Verifying Java

A.1.2. Database setup

A.2. Installing SonarQube

A.2.1. Ubuntu

A.2.2. Windows 7

A.2.3. Configuring SonarQube: Windows 7 and Ubuntu

A.2.4. Turning it on

A.2.5. Default admin account

A.3. Upgrading

A.3.1. Ubuntu

A.3.2. Windows 7

Appendix B. Analysis

B.1. Analyzing with SonarQube Runner

B.1.1. Install: Windows 7

B.1.2. Install: Ubuntu

B.1.3. Verify and configure : Ubuntu and Windows 7

B.1.4. Analyze

B.1.5. Multi-module projects

B.2. Analyzing with Maven

B.2.1. Setup

B.2.2. First analysis

B.2.3. Multi-module

B.3. Analyzing with Ant

B.4. Analysis properties

Index

List of Figures

List of Tables

List of Listings

Foreword

The software industry is still a young industry in which software quality means for many people pain, cost, constraint, nice to have, one-shot effort, or external reviews. Fortunately, with the Agile movement, the industry has started to realize during the last decade that software quality also means fun, built-in, rewarding, and higher productivity. Ann Campbell and Patroklos Papapetrou belong to the latter group, and they strongly believe that software quality should be a daily concern shared by all stakeholders in the industry for long-term success.

Software quality is divided into external and internal quality. External quality looks at how well the software fulfills its functional requirements: in other words, whether you’re building the right software. Internal quality looks at how well the software is designed/implemented to constantly welcome new changes: in other words, whether you’re building the software right. Industry statistics show that on average, 80% of the cost of software is spent on maintenance; there is considerable variability depending on internal quality. This makes internal quality a key component for the future cost of software.

This is the reason why managing code quality of applications has become a major concern for any company that builds or is involved in building software. Traditional approaches to managing code quality propose to test code from time to time, mainly at the end of a development phase. In the best case, this approach leads to delays and re-work; in the worse case, it leads to the shipment of poor-quality, expensive-to-maintain software. There is therefore an urgent need for a new approach: one that clearly gives ownership of code quality back to the development team; one that emphasizes quality throughout the development phase and has a shorter feedback loop to ensure rapid resolution of quality problems; in short, a model that builds in quality from the start, rather than considering it after the fact.

This is the mission we have set ourselves at SonarSource: to provide tooling for support of this new approach called Continuous Inspection. This is what we believe we have achieved with SonarQube, the open source platform to continuously manage technical debt. SonarQube has a large ecosystem, is widely adopted, and has a very large community. Ann and Patroklos are part of this community and among the most active members, contributing not only by their feedback but also by expanding the ecosystem. When they approached me with the idea of writing a book, I was thrilled, because this is clearly something that is missing in the SonarQube ecosystem. Having Ann and Patroklos writing it also meant it would have some great insight from the community and, more important, that it would contain the end-user perspective on the solution.

This book will be your companion in your journey with SonarQube. It will take you from why you should use SonarQube to installation, configuration, administration, and utilization of services, up to extending the platform. You can use it either by reading through from A to Z or as a support reference for information about a specific topic.

But that isn’t all! Ann and Patroklos also discuss the process surrounding the tool, challenge existing and missing functionality, and provide numerous tips for using SonarQube, all based on their own experience. Whatever your level of familiarity with the product, you’ll learn from this book. This is what, in my opinion, makes this book a unique source of information for a successful implementation.

Enjoy!

OLIVIER GAUDIN

CEO AND COFOUNDER

SONARSOURCE

Preface

Would you like to help me write a book about Sonar? My reaction was immediate: Yes!

I knew Patroklos Papapetrou from the Sonar mailing list, and I was aware that he was pitching Sonar in Action (now SonarQube in Action, to match the technology’s new name) to Manning. What I didn’t know was that he wanted a coauthor. Because I was a native English speaker and active (and helpful) on the list, he thought of me. I had only been a member of the list for about six months, but I’d been aware of Sonar since late 2008 when my boss came across a mention of Sonar and asked me to evaluate it.

I was coding in Java at the time, but I had started my programming career with Perl and C. Lint was your friend, and bugs were found the hard way—by the users. So I found Sonar intriguing. It promised to scan each line of code and point out all kinds of things that were wrong or could go wrong. But to use it, you had to be building with Maven. Unfortunately, we were in an Ant-build shop. Sonar was off the table.

Fast-forward to early 2010. Sonar was approximately three years old, but already it was gaining broad acceptance among community and enterprise users and being downloaded more than 2,000 times a month. Patroklos had found the Sonar website while researching software quality tools, and it was a classic boy-meets-software story. (Cue the sappy music.) It didn’t take long before he was in love and Sonar was one of his favorite tools.

Meanwhile, I had begun moving our Ant builds to Jenkins (it was still called Hudson then), and I stumbled across the Sonar plugin for Hudson. It works differently now, but at the time, it performed a shallow Maven-ization of a non-Maven project and ran an analysis. Hmmm. Maybe Sonar was back on the table.

I installed Sonar and the plugin on my localhost and ran an analysis. When I poked around in the results, I didn’t understand everything I was seeing, but I knew I liked the way it presented issues in the context of the offending code. And because Sonar had a web-based front end, instead of having to send quality reports to people, I could send the people to the reports! When I showed my colleagues, they agreed that what we were seeing was good stuff, so we teamed up on our management.

We pretty quickly got first-level management’s buy-in to pilot Sonar, and we started talking about it to anyone who would listen. Pretty soon other teams were approaching me to set them up with that Sonar thing. We were seeing a viral adoption. After only a couple of months, management at the next level up said that everyone needed to be on Sonar by the end of the year.

By this time it was early 2011, and Patroklos was an active member of the Sonar community. He had spent 2010 telling everyone he knew about Sonar via his articles and blog posts. He also implemented his first Sonar plugin that year. By August of 2011, he was such a prominent figure in the small Sonar community that another publisher approached him to write a book about it. He was flattered, but didn’t have the time to do it justice, so he turned it down.

But although Patroklos didn’t write that book, he didn’t forget the idea. When his schedule cleared at the end of the year, he approached Manning about writing Sonar in Action. A few short months after that, we were on our way.

Our goal in writing this book has been to condense the SonarQube lessons we learned in the last few years, combine them with whatever wisdom we can lay claim to from our combined 30 years of programming, and put a bow on all of it for you. The first time I ran a Sonar analysis, I didn’t understand some of the things I was seeing, but we don’t want that to happen to you. We’ll tell you not only what SonarQube’s metrics mean, but also why you should care and (unless it’s really, really obvious) what steps to take in your code to get started fixing what’s wrong. We’ll help you plan a strategy for tackling your technical debt, and we’ll show you how to make SonarQube a part of your routine rather than something extra you have to remember to do. We’ll guide you in twiddling SonarQube’s knobs so you can tune it to get the best experience in your environment. And finally, in case you feel the need, we’ll show you how to get started writing your own SonarQube plugin.

Over and over, I’ve seen this in action: good programmers are passionate about quality code. Show us what the problems are, and we’ll be almost compelled to fix them. In the past, the hard part has been pinpointing the problems. With SonarQube, the only hard part is finding the time to deal with them. Code quality used to be hard. Now it’s easy. Welcome to SonarQube.

ANN CAMPBELL

Acknowledgments

When we signed up to write this book, we didn’t know how much effort it would require. It was for both of us our first authoring attempt, and although Ann had considerable experience with documentation and journalism, Patroklos’s most recent writing had taken place a decade earlier. Without the assistance of many people, this book would definitely not be in your hands or on your screen right now. It’s much more likely that we would still be working on it.

From day one of the project, help has poured in, and all of it has been not only appreciated but essential. If we’ve forgotten anyone, please accept our sincere apologies. In no particular order, we’d like to thank the following people for their work and support.

Manning Publications

Many thanks to publisher Marjan Bace for accepting the initial proposal of two new and inexperienced authors. He helped the book take its first—and most important—step.

Thanks to Christina Rudolph and Michael Stephens, who were the first two people we talked with about the book. They guided us as we improved our proposal, and they explained the publishing process in detail.

Hillary Clinton said it takes a village to raise a child. It turns out that it takes one to produce a book, too. Clearly, our development editor, Susanna Kline, deserves a shout-out for her continuous support and help. Her patience and encouragement were invaluable.

Thanks to Bert Gates and Cynthia Kane for teaching us how to write our first chapters following Manning style.

Thanks to Candace Gillhoolley for her marketing efforts on the first MEAP release. She is a master of social media.

Knowing that we didn’t have to worry about every semicolon because a copyeditor would come after us has been tremendously freeing; our thanks to Tiffany Taylor. And thanks to many other members of the Manning team who helped us behind the scenes: Maureen Spencer, Kevin Sullivan, Olivia Booth, Toma Mulligan, Mary Piergies, Dottie Marsico, and Janet Vail. And special thanks to our technical proofreader, Craig Smith, for his final review of the manuscript shortly before it went into production.

The SonarSource team

Of course, without SonarQube itself, the book wouldn’t have been possible. That puts the folks at SonarSource squarely at the front of the line for thanks for their incredible free and open source contribution to software quality. More than simply providing the software, they’ve actively supported this book. SonarSource CEO Olivier Gaudin and Product Director Freddy Mallet reviewed each chapter, offering invaluable feedback and insight. The fact that we have their blessings and support ... wow. We couldn’t ask for more. Without their help, we wouldn’t have been able to publish this book with the most updated material.

The reviewers

Thanks to our MEAP readers and to the reviewers who read the manuscript at various stages during its development and gave helpful comments and feedback to our editors and to us: Alex Garret, Bobby Abraham, Brandon Campbell, Chris Baxter, Christopher Taylor, Gregor Zurowski, Jason S. Shapiro, Javier Garcia Martin, Joshua White, Mark Elston, Michael Hüttermann, Mikkel Arentoft, Rashid Jilani, Reinhard Prehofer, Robert Wenner, and Steven Hicks.

Ann Campbell

I’d like to thank my husband, Charles Nix; my dog; and the rest of my family for their patience with me this past year as I concentrated on writing rather than on ... really, anything else in my life.

I’d also like to thank my high school English teacher, Dr. Richard L. Handlesman (Doc to his students), for forcing me to write an essay every two weeks; and my mother, Polly Campbell, for teaching me to write them (whether I wanted to learn or not).

Patroklos Papapetrou

I’d like to thank my loving and beautiful wife, Anna, for her patience all these months, especially during the weekends. Without her encouragement, I wouldn’t have managed to finish my part of the book. Thanks to my sons, Panagiotis (age 4) and Charis (age 2), who understood that sometimes Daddy couldn’t play with them or go to the park. You can have me back now! Thanks to our families for their patience as well and for sometimes watching the kids to let me work on the book.

About this Book

Welcome to SonarQube in Action. This book is aimed at turning all the tedious and sometimes hard-to-understand stuff about source code quality and software metrics into an exciting experience. It aims to become the Holy Bible of software quality: a reference for every development team that wishes to improve their source code. You’ll see that metrics are meaningful and affect several aspects of your software’s health. In this journey, SonarQube will be our pilot. SonarQube is an open source platform for continuously measuring, managing, tracking, and improving source code’s quality.

How this book is organized

We begin each chapter of the book by describing a real problem/situation, and then we talk about the features of SonarQube and the relevant metrics that help you address and eventually solve that problem. We elaborate by providing some theoretical background, we discuss best practices (if any), and we end each chapter by talking about relevant—to the chapter’s topic—SonarQube plugins and how you can take advantage of them.

Now it’s time to list in detail the book’s content.

Part 1 gives you an overview of SonarQube, explains the seven axes of quality (like the seven deadly sins of software development), and sets the stage for the following parts. We introduce SonarQube’s key features and benefits and discuss the core metrics that SonarQube calculates.

Chapter 1 sets the scene, introducing the core concepts of SonarQube. We begin by showing you what you should expect to see when you analyze a project using SonarQube for the first time. We briefly discuss the different metrics presented in SonarQube’s dashboard. At the end, we present the Technical Debt plugin.

Chapter 2 introduces the topic of code issues. You’ll learn, among other things, where they come from and how they’re related to bugs or potential bugs.

Chapter 3 is all about testing (unit and integration). It describes the importance of code-coverage metrics and how they’re calculated, and it gives you some tips for improving the test quality and coverage of your code.

Chapter 4 focuses on duplicated code by illustrating the problems that may arise and the resulting impact on the quality and maintainability of your source code.

Chapter 5 deals with a topic which is rarely considered by development teams as a quality factor: documentation. You’ll find out when and why it’s a good practice to document your code, and we’ll present a proposed documentation strategy that fits any development process.

Chapters 6 and 7 talk about design and complexity. Although some may argue that they’re more or less the same thing, we’ve chosen to split them in order to provide more examples and illustrate their value in code quality.

Part 2 discusses how you can get the best out of SonarQube, where it fits in any development lifecycle, and how to make it part of your everyday work life. It also introduces the concept of Continuous Inspection, which is the ultimate target when talking about software quality.

Chapter 8 discusses several approaches for improving the quality of your source code. You can pick one or all of them based on your experience. Then we’ll take you on a tour of all the possible data perspectives that SonarQube offers, and we finish by explaining the concepts of history and trending.

Chapter 9 delves into the details of Continuous Inspection. We’ll talk about integrating SonarQube with Jenkins, and you’ll learn about the star feature of differential views that lets you track quality evolution over time.

Chapter 10 deals with the popular practice of code reviews and explains how you can benefit from SonarQube. You’ll find out how issues are associated with reviews, how to track them, and what SonarQube features let you plan your work with action plans.

Chapter 11 talks about integrating SonarQube with Eclipse. Enjoy most of the SonarQube advantages without leaving your IDE by following the step-by-step guide provided in this chapter.

Part 3 covers several administrative topics and gives you ideas about customizing and tuning SonarQube to make it suitable for any kind of project. In an enterprise environment with a SonarQube installation that hosts several projects, it’s a good idea to adjust many of SonarQube’s predifined settings to fit your needs. This part of the book also teaches you step by step how to extend SonarQube by writing a custom plugin.

Chapter 12 explores security concepts, including users, roles, and groups. You’ll learn how to delegate authentication and authorization to external systems (LDAP, OpenID, and so on).

Chapter 13 deals with managing coding rules and organizing them in quality profiles. You’ll also discover how you can create your own rules or edit existing ones and trigger alerts when metrics fall below a threshold.

Chapters 14 and 15 discuss global and project administration, including filters, dashboards, and user notifications. The latter also provides a simple path for adopting Continuous Inspection by discussing useful SonarQube features that will assist you in this direction.

Chapter 16 is dedicated to teaching you how to extend SonarQube. Although it’s not possible to cover everything in a few pages, we provide a complete example of implementing a real SonarQube plugin. We also give you some insights into adding support for new programming languages.

The book also has two appendixes that will help you with the basics, especially if you’re a SonarQube newbie:

Appendix A focuses on installing SonarQube in Linux and Windows.

Appendix B provides all the necessary details to run your first analysis with SonarQube.

One last thing—don’t expect to find correct code in this book. Chapter 16 is the only exception to that rule, because it deals with writing plugins. Most of the examples intentionally illustrate bad habits in coding, and their purpose is to point out what you should avoid. Nevertheless, in some cases we’ve included a refactored version to show you that by using SonarQube, you can begin to understand these nasty metrics and dramatically improve the quality of your code.

How to use/read this book

Each person has their own reading style, and we can’t force you to change it for this book. But we can still give you a couple of ideas on how to get the most out of this book.

Every chapter is organized in such a way that you can read it separately from the rest. We do suggest that you read chapter 1, especially if you’re not an experienced SonarQube user, because it’s an overview of SonarQube and introduces some basic ideas you may need when reading the rest of the book.

If you decide to read the book sequentially, you’ll find that each chapter is connected to the previous one, and the chapters flow smoothly, without gaps. But again, you can skip any chapter and come back later if you want to.

We did our best to ensure that this book will become a reference for you whenever you need to learn or remember anything about SonarQube or its computed metrics.

Who should read this book

Believe it or not, source code quality is a topic that targets almost everyone who participates in a software project. Although we provide several code examples, you don’t need to be a code expert to read this book. You also don’t need to be familiar with Java, because the code listings and snippets are so simple that anyone with basic programming skills can understand them. Besides, don’t forget that most of the examples in the book show you poor or bad code, to illustrate techniques and habits you should avoid. We do expect that you have some basic knowledge about software quality metrics.

The book is aimed at the following professionals:

Software engineers (developers, designers, architects)—This is the book’s primary target audience. Software engineers live a day-by-day battle to achieve software quality, hunting and fixing bugs, adding new features, and designing and redesigning the logical architecture of the system. Not to mention that all these things have to be done within strict deadlines and constantly changing business requirements. This book will help you spot the parts of the software that need your attention so you can take immediate action.

Quality assurance staff and testers—QA stuff nowadays plays a valuable role in software engineering. In most cases, these people are part of the development team, and it’s up to their judgment whether a product should be released. If you fall in this category, this book will teach you how to track the quality of the software under devlopment in an easy and comprehensive way, how to define criteria and thresholds for critical metrics, and, eventually, how SonarQube can assist you in decision making.

Project/Product managers and team leaders—The era of project/product managers and team leaders sitting in an office, isolated from the rest of the development team, has passed. Managers exist to do more than read weekly reports and track down timelines and deliverable. They must have a clear view of the software and especially its quality in order to assist team members and get them on the right track. This book explains all the quality axes without unnecessary technical details. It provides you with a guide to how you can automatically track quality measures in source code over time and improve the development lifecycle by introducing new practices such as code reviews and Continuous Inspection.

Code conventions and downloads

All the source code in the book, whether in code listings or snippets, is in a fixed-width font like this, which sets it off from the surrounding text. In most listings, the code is annotated to point out the key concepts, and numbered bullets are sometimes used in the text to provide additional information about the code. We have tried to format the code so that it fits within the available page space in the book by adding line breaks and using indentation carefully.

Source code for all the examples and the plugin from chapter 16 are available at www.manning.com/SonarQubeinAction. If you want to get the most updated source code for the plugin—remember, it’s a real one, so the latest version is likely to be different from the code shipped with the book—it’s available at the following GitHub link: https://github.com/ppapapetrou76/sonar-redmine-plugin.

What this book doesn’t do

This book should not be considered a user or administration guide for SonarQube. If you just want to learn how to use SonarQube, the online documentation at http://docs.codehaus.org/x/EoDEBg should be sufficient.

This book also doesn’t explain the underlying tools with which SonarQube integrates, such as PMD, FindBugs, Checkstyle, and so on. You’re encouraged to visit the corresponding websites to learn more about their purpose.

In some chapters, we include tips and best practices for refactoring as well as some introductory material. But this book doesn’t teach you how to refactor your code.

Author Online

The purchase of SonarQube in Action includes free access to a private web forum run by Manning Publications, where you can make comments about the book, ask technical questions, and receive help from the authors and from other users. To access the forum and subscribe to it, point your web browser to www.manning.com/SonarQubeinAction. This page provides information on how to get on the forum once you are registered, what kind of help is available, and the rules of conduct on the forum.

Manning’s commitment to our readers is to provide a venue where a meaningful dialogue between individual readers and between readers and the authors can take place. It is not a commitment to any specific amount of participation on the part of the authors whose contribution to the forum remains voluntary (and unpaid). We suggest you try asking the authors some challenging questions lest their interest stray!

The Author Online forum and the archives of previous discussions will be accessible from the publisher’s website as long as the book is in print.

About the authors

G. ANN CAMPBELL has 15 years of experience in Perl, C, C++, Java, and web technologies on variously sized and organized teams, and she has spent far too much time achieving code quality the hard way without SonarQube.

PATROKLOS P. PAPAPETROU is a Java architect, an experienced software developer, and an Agile team leader. He’s an active SonarQube community member and contributor.

About the Cover Illustration

The figure on the cover of SonarQube in Action is captioned Habit of a Bonze of China in 1700. A bonze is a Buddhist monk. The illustration is taken from Thomas Jefferys’ A Collection of the Dresses of Different Nations, Antient and Modern (4 volumes), London, published between 1757 and 1772. The title page states that these are hand-colored copperplate engravings, heightened with gum arabic. Thomas Jefferys (1719–1771) was called Geographer to King George III. He was an English cartographer who was the leading map supplier of his day. He engraved and printed maps for government and other official bodies and produced a wide range of commercial maps and atlases, especially of North America. His work as a mapmaker sparked an interest in local dress customs of the lands he surveyed and mapped, which are brilliantly displayed in this four-volume collection.

Fascination with faraway lands and travel for pleasure were relatively new phenomena in the late 18th century, and collections such as this one were popular, introducing both the tourist as well as the armchair traveler to the inhabitants of other countries. The diversity of the drawings in Jeffreys’ volumes speaks vividly of the uniqueness and individuality of the world’s nations some 200 years ago. Dress codes have changed since then and the diversity by region and country, so rich at the time, has faded away. It is now often hard to tell the inhabitant of one continent from another. Perhaps, trying to view it optimistically, we have traded a cultural and visual diversity for a more varied personal life. Or a more varied and interesting intellectual and technical life.

At a time when it is hard to tell one computer book from another, Manning celebrates the inventiveness and initiative of the computer business with book covers based