Part VI. Quality Metrics Tools

“And I know it seems easy,” said Piglet to himself, “but it isn’t every one who could do it.”

“A House Is Built at Pooh Corner for Eeyore,” The House at Pooh Corner, A. A. Milne

Despite all appearance to the contrary, writing good, reliable, flexible, maintainable, high-quality software is not an easy task. However, Java developers do not have to learn everything from scratch. Years of good programming habits have been codified in the form of coding standards and best practices.

Coding standards are a key part of many development processes, and for good reason. These standards codify (no pun intended) time-honored traditions and conventions, as well as best practices in the art of software writing. Some recommendations simply define a standard way to layout code or to name classes or variables, while others are designed to make code more reliable or better performing. However, as Andrew S. Tanenbaum, professor of Computer Science at Vrije Universiteit, Amsterdam, and author of the Minix operating system, said, “The nice thing about standards is that there are so many to choose from.” Different companies, teams, and individual developers have developed different programming practices and habits over time. The problems start when developers who use different programming styles and conventions have to work together on a common code base. Indeed, many standards, such as indentation and naming conventions, are fairly arbitrary things. Should the curly brackets go directly after the instruction, as recommended by the Sun coding conventions?

while (i < 10) {
    i++;
}

Or should they be on a new line, as used by many C++ developers?

while (i < 10) 
{
    i++;
}

There is no real objective reason to prefer one style over the other: the important thing is to have a well defined and accepted style within your project. Recognized coding standards help to harmonize the way a team or company works together. Once team members are familiar with an established set of coding standards, they will think less about details such as code layout and variable naming conventions and can concentrate better on the real work of coding. New project teams will lose less time at the start of a project making decisions of earth-shattering importance such as where to put the curly bracket after the if statement. The consistent use of standards also encourages a feeling of “esprit de corps” within a team or company. And code that is laid out consistently and that follows well-known conventions is easier to read, understand, and maintain. Sun has defined a set of coding conventions for the Java language that is widely accepted in the industry. Many companies and open source projects also publish their own set of coding conventions, often variations of the Sun conventions. A few typical coding standards are given here:

  • Comments

    • Write Javadoc comments for all classes, methods, and variables.

  • Naming conventions

    • Class names should be nouns, in mixed case with the first letter of each internal word capitalized (MyClass).

    • Variable names should be nouns, in mixed case with a lowercase first letter, and with the first letter of each internal word in upper case (myVariable).

    • Constants should be in all uppercase with words separated by underscore (MY_CONSTANT_VALUE).

  • Indentation

    • Spaces should be preferred to tabs for indenting purposes.

  • Declarations

    • One declaration per line, with comments, for example:

      int class; // The child's class, from 1 to 8
      int age;   // The child's age

      rather than:

      int class, age;
      
  • Statements

    • Opening braces in compound statements should be at the end of the line that begins the compound statement; the closing brace should begin a line and be indented to the beginning of the compound statement, for example:

      while (i < 10) {
          i++;
      }
  • Best Practices

    • Use the final keyword for variables and parameters that will not need to be modified.

    • Don’t declare variables within loops.

It is always a good idea to discuss the conventions to be applied within your company or project with all members of the development team. Each rule should be explained and justified. What is the underlying goal of the rule? Is the rule to be applied systematically, or can there be exceptions? As with many best practices, coding standards must be well understood by the whole team to be effective.

Indeed, like all technologies, software metrics can be used and abused. Coding standards and best practice rules should under no circumstances be applied blindly, nor should they be used as a way for management to evaluate team member performance. Rather, when issues are raised, they should be used as discussion topics, to point out potential coding errors or poor practices, or to tailor the rule set to correspond more closely to your team’s programming style. When used well, software metrics can provide valuable feedback on the quality of the code being written, and allow the development team to learn and progress. To be successful, software metrics should be considered a team sport.

There are many static analysis tools around. In this section, we look at three of the most well-known: Checkstyle, PMD, and FindBugs.

Checkstyle is an open source tool that can help enforce coding standards and best practices, with a particular focus on coding conventions. It can be used as a standalone tool to generate reports on overall code quality, and can also be incorporated into the developer’s work environment, providing real-time visual feedback about the code being written.

Static code analysis is another technique that can complement code reviews in preemptively finding potential errors or poor coding practices. It involves analyzing the structure of classes and detecting potentially dangerous patterns of code. By automatically detecting certain types of coding issues, static analysis tools can save time and energy in code reviews, and help encourage good coding practices. Although Checkstyle does cover some static code analysis features, we will also look at two other tools that are more specialized in this area: PMD and FindBugs. PMD can help to flush out a wide range of potential bugs and poor coding practice. FindBugs differs from the other two tools in concentrating exclusively on potential bugs, dangerous programming practices, and possible performance issues.

Code reviews are another highly effective way to improve code quality. Unfortunately, they are rarely practiced with any consistency. Using code analysis tools can reduce a lot of the drudgery involved with code reviews, by automatically checking coding standards and best practices. However, a human eye will always be able to see issues that a machine cannot. Another interesting tool that can help out with code reviews is Jupiter, an Eclipse plug-in that you can use to help set up an electronic code review process.

We will also look at Mylyn in this section. Although not directly related to code quality, this innovative eclipse plug-in does help users write better code by helping to manage their tasks more effectively, and to focus on the project resources relevent to the task at hand, filtering out the others.

Finally, tools such as QAlab and StatSCM keep track of various project metrics such as static code analysis results, test coverage, and the size and contents of your source code repository, and provide you with invaluable statistics about how your project evolves over time.

All these tools are highly configurable. The best coding standards and recommended practices are determined collaboratively, with active buy-in from the whole team.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.218.136.90