In a previous post by another ChaiOne’er, Lavanya Sukumar discussed the cost of quality. And here in this post, we are going to discuss code quality and how to improve it with the assistance of static code analysis tools. Like no one prefers a car with low quality tires as that might put drivers in danger, people won’t use software of low quality either. However, all programs always contain defects, and many of which aren’t explicit.
So software inspection was introduced as a technique to improve software quality. There are at least two approaches to inspect software quality. One is, as dynamic analyses do, to examine the behavior during the run-time of the code. Developers, as Anthony and Kevin discussed in their posts about KIF testings (Anthony’s post and Kevin’s post), can write unit tests and behavior tests to help us identify if programs satisfy the expectations.
Meanwhile, testers can actually run the program in a perspective of the end users, and verify the program works properly. On the other side, as software are developed by lines of source code, a good code quality becomes the first step towards a high quality of software. Static code analysis tools, inspecting and analyzing the source code of the program before it is tested, lower the cost of finding and fixing bugs in software in the early stage of the development cycle. So employing static code analysis tools is one of the best practices in software development.
Even though developers work so hard try to produce high quality software, but developers are human-beings, and everyone make mistakes. So it’s extremely hard to guarantee things can be done correctly for the first time. Sometimes, developers also write “quick and dirty” code under the pressure of deadline. Code smells, symptoms that indicate deeper problems in the source code, could be introduced by developers when write code.
Literally, smelly code is hard to read and understand. Essentially, code smells have their patterns, such as duplicated code, long method, god class, long parameter list, etc. Code smells are one type of technical debts, and will incur interests if not be paid off on time. Even worse, according to the Broken Window Theory, if poor quality of code is not amended, the tendency by developers to break code will grow. Once code quality starts going down, the neglect accelerates the rot faster than any other factors, and the project could goes out of control eventually.
Code smells, as people describe them, have their patterns in code. Static code analysis tools can help recognize the patterns of these code smells. Similar to accountants auditing for red flags in financial reports, static code analysis tools can traverse source code, identify code smells by detecting a series of error patterns, and generate diagnostic reports finally. Static code analysis tools works very well with continuous integration systems.
Whenever developers make changes to the source code repository, continuous integration systems can be triggered to build the entire program, run the static code analysis along the way. By doing this, static code analysis can be done continuously. If code smells are detected, email notifications, which ask for future actions, can be sent to the developers. Employing static code analysis tools and fixing all code smells are strict principles to developers.
However, people already learned from experiences that the consequences of poor quality code can be terrible, and sometimes impossible to undo. So it’s extremely worthy to improve code quality under the assistance of code analysis tools. At ChaiOne, we care about code quality, because it has many benefits to us. With high quality of code, we are able to not only produce high quality of software that clients satisfied, but also eliminate the risk of defects and reduce the cost of fixing potential problems after the software is actually shipped to the users.
As a concrete example, for all our iOS projects at ChaiOne, we use OCLint, a static code analysis tools for Objective-C, to improve our code quality. Whenever our iOS developers push their latest changes to our code repositories, our continuous integration system, Jenkins, will automatically start compiling the project, and trigger OCLint to run. The reports generated by OCLint will be visible to the developers. Figure 1 is a screenshot of sample report of GamePlan iPad client. According to the list of items in the report, developers can attack them isolated, clean code smells, and move on. By continuously doing this, our code becomes easy to read and understand, open to change, and has low cost and risk of maintenance.
To sum it up, static code analysis tools are not a silver bullet to ship successful software, but they are important and very handy tools to achieve high code quality. As a result, will help developers produce successful software of good quality eventually.