In software development, a “code smell” is usually considered a surface indicator of an underlying problem. This term, thought to be coined by Kent Beck in the late ’90s, is not generally a bug that keeps the program from operating, but rather a weakness that could cause issues down the road. The biggest hassle with a code smell is that by the time you get a whiff, the software is generally already running somewhere.
One technique that has been around for a while to help ferret out troublesome code before it ends up in the hands of your customer is static analysis. When someone first suggested I let another program analyze my code for weaknesses, I was pretty skeptical; in fact, I was kind of insulted.
Over time, though, I’ve not only warmed up to the idea but come to appreciate the insight static analysis can provide. In particular I find SonarQube to be very Android friendly. If you’ve never used it before, the tutorial below will give you a sense of what to expect.
Using SonarQube to find code smells
2. Unpack the ZIP file on to your local drive. On OS X I generally place the sonarqube-x folder in /Applications.
3. You will probably want to add the sonarqube-x/bin/<os> folder to your current path. On my Mac this means:
If you’re on a Windows box, it will probably look something more like:
set PATH=%PATH%;âC:\Program Files\sonarqube-4.5/bin/windows-x86-64/â
4. Start the SonarQube server. The Mac command is:
Windows users should run:
5. If everything goes okay, you should be able to reach SonarQube by throwing the following link into your favorite browser: http://localhost:9000 (Figure A).
6. Now you have the Sonar server up and running. There are several techniques available for analyzing your source code, including ANT integration, Gradle integration, and a standalone SonarQube Runner. You can read all about the options available on the SonarQube documentation repository, but to keep things simple and universal, I’m going to demonstrate the standalone SonarQube Runner.
7. Download the package for the standalone runner. Just like in step 3, you’ll want to unpack the file and add the /bin folder to your existing path.
8. Any Android project you want to analyze with SonarQube needs a sonar-project.properties file in the project root directory. I decided to analyze a project I built last year as part of an Android bootcamp series. The project folder is called /Bootcamp, so this is where I will place my sonar-project.properties file.
9. In most cases, you’ll be able to use the default properties file, changing only the project key and project name.
# Required metadata
# Path to the parent source code directory.
# Path is relative to the sonar-project.properties file. Replace "\" by "/" on Windows.
# Since SonarQube 4.2, this property is optional if sonar.modules is set.
# If not set, SonarQube starts looking for source code from the directory containing
# the sonar-project.properties file.
# Encoding of the source code
# Additional parameters
10. At last we are ready to analyze the code! From a command prompt, change to the root directory of your project (in my case, /Bootcamp) and execute sonar-runner. If everything goes as expected, you should see something like Figure B.
11. Go back to your web browser and hit refresh. Look for your project analysis summary (Figure C).
12. The tool believes I have about a day and a half of technical debt in this project. To get specific recommendations, I can drill down. My project has no critical issues, but quite a few deemed major. Let’s have a look (Figure D).
13. The breakdown shows great recommendations if this project was something I was planning to maintain long-term (Figure E), though nothing that is preventing my code from running. Best of all, I can continue to drill down and get an exact line number in a source file.
At the end of the day, SonarQube is a piece of software written by a developers just like you and me. In other words, it’s not perfect. The analysis engine is aware of syntax and even context but not intent. It’s not a replacement for the judgment of a seasoned software engineer. It can, however, be a great way to look for code smells and be a friendly reminder of all the best practices we, as diligent developers, should be striving to code by.