Professional Documents
Culture Documents
How Statical Analysis Can Help You Reduce Testing Process For Java Software
How Statical Analysis Can Help You Reduce Testing Process For Java Software
How Statical Analysis Can Help You Reduce Testing Process For Java Software
Application ICESCRUM2
Audit Report
2010-02-10
Kalistick
13 av Albert Einstein
F-69100 Villeurbanne
+33 (0) 486 68 89 42
contact@kalistick.com
www.kalistick.com
Code audit of IceScrum2 application 2010-02-10
1 Executive Summary
The Quality Cockpit uses static analysis techniques: it does not execute the application, but analyzes the
elements that compose it (code, test results, architecture ...). The results are correlated, aggregated and
compared within the project context to identify risks related to quality. This report presents the results.
Origin of non-compliances
Report Organization
This report presents the concepts of Quality Cockpit, the goal and the associated technical requirements
before proceeding with the summary results and detailed results for each technical area.
2 Introduction
The analysis process is based on the "Quality Cockpit" platform, available through SaaS1 model
(https://cockpit.kalistick.com). This platform has the advantage of providing a knowledge base unique in that
it centralizes the results from statistical analysis of millions code lines, enriched continuously with new
analyses. It allows performing comparative analysis with other similar projects.
The results are given through an analytical approch based around three main dimensions:
The quality factors, which determine the nature of the impact of non-compliances detected, and the
impact on the quality of the application
The quality domains, which specify the technical origin of non-compliances
The severity levels, which positions the non-compliances on a severity scale to characterize their
priority
1
Software as a Service: application accessible remotely via Internet (using a standard browser)
Maintainability. Ability of software to be easily repaired, depending on the effort required to locate,
identify and correct errors.
Reliability. Ability of software to function properly in making the service expected in normal
operation.
Changeability. Ability of software to be able to evolve, depending on the effort required to add,
delete, and modify the functions of an operating system.
Security. Ability of software to operate within the constraints of integrity, confidentiality and
traceability requirements.
Transferability. Ability to perform maintenance and evolution of software by a new team separate
from the one which developed the original software.
Efficiency. Relationship between the level of software performance and the number of resources
required to operate in nominal conditions.
Implementation. The problems inherent in coding: misuse of language, potential bugs, code hard to
understand ... These problems can affect one or more of the six quality factors.
Structure. Problems related to the code organization: methods too long, too complex, with too many
dependencies ... These issues impact maintainability and changeability of the application.
Test. Describes how the application is tested based on results of unit tests (failure rate, execution
time ...) but also of the nature of the code covered by the test execution. The objective is to ensure
that the tests cover the critical parts of the application.
2
ISO/IEC 9126-1:2001 Software engineering — Product quality — Part 1: Quality model :
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=22749
3
The analysis focuses on a subset of ISO 9126 in order to focus on controllable dimensions automatically.
Architecture. Problems with the software architecture of the application. The platform allows the
definition of an architectural model to modularize the application into layers or components and
define communication constraints between them. The analysis identifies in the code all the calls
which do not satisfy these constraints, to detect the maintainability, changeability and security risk
levels.
Documentation. Problems related to lack of documentation in the code. This area primarily impacts
the transferability of code.
Duplication. Identification of all significant copy-pastes in the application. They impact reliability,
maintainability, transferability and changeability.
To simplify interpretation, the severity levels are expressed using a four-level scale. The first is an error, the
others are warnings, from most to least severe:
Forbidden
Highly inadvisable
Inadvisable
To be avoided
Compared to the Forbidden level, other levels of severity are managed with a tolerance threshold, which
increases inversely with gravity.
3 Quality objective
One of distinctive features of "Quality Cockpit" is to perform the analysis according to real needs of the
project in terms of quality, in order to avoid unnecessary efforts and to ensure greater relevance of quality
risks.
These requirements are formalized by defining the "quality profile" of the application, which characterizes
the quality levels expected on each of the six main quality factors. This profile is then translated as "technical
requirements" which are technical rules to be followed by the developers.
Objective: avoid bad practices and apply best practices related to the
technology used.
Size of methods Number of statements. This measure is different from the number of lines
of code: it does not include comment lines or blank lines but only lines with
at least one statement.
Complexity and Identifies methods difficult to understand, test and maintain because of
coupling of methods moderate complexity (cyclomatic complexity) and numerous references to
other types (efferent coupling).
This rule requires a minimum level of testing (code coverage) for each
method of the application according to the TRI (TestRelevancyIndex); TRI
for each method assesses the risk that it contains bugs. His calculation takes
into account the business risks defined for the application.
Test
Objective: focus the test strategy and test efforts towards sensitive areas of
the application and check them. These sensitive areas are evaluated
according to their propensity to contain bugs and according to business
risks defined for the application.
Details of the thresholds are provided in the annex to the report (8.4.2 Code
coverage).
Rules defined See the architecture model defined for the application to check architecture
specifically through the constraints.
Architecture
architecture model.
Objective: ensure that developments follow the expected architecture
model and do not introduce inconsistencies which could be security holes,
maintenance or evolution issues.
Note: violations of architecture are not taken into account in the calculation
of non-compliance.
duplications
Objective: detect identical blocks of code in several places in the
application, which often causes inconsistencies when making changes, and
which are factor of increased costs of testing and development.
4 Summary of results
This chapter summarizes the status of the project using global indicators. These indicators measure the
intrinsic quality of the project, but also compare its situation to other projects using “Quality Cockpit”
knowledge base.
Specifically, this represents the ratio between the total number of statements, and the
number of statements in non-compliant classes. A class is considered as non-compliant if at least
one of the following statements is true:
The level of non-compliance is calculated for each quality factor, and then weighted by the
level of requirements set for the related quality factor.
Detailed results specify for each quality factor: the number of non-compliant classes, the
number of violations for selected rules, and the percentage of application code involved in non-
compliant classes.
This chart compares each field according to the impact of rules that are associated with
the quality of the application. The impact is measured from the number of statements in classes
non-compliant.
4.1.4 Volumetry
The following table specifies the volume of the analyzed application:
A "line" corresponds to a physical line of a source file. It may involve a white line or a
comment line. A "statement" is a primary unit of code, it can be written on multiple lines, but
also a line may contain multiple statements. For simplicity, a statement is delimited by a
semicolon (;) or a left brace ({).
4.2 Benchmarking
The “Quality Cockpit" knowledge base allows a comparative analysis of the project with other projects
reviewed on the platform. The objective is to measure its level of quality compared to an overall average.
The “Intra-Cockpit” projects: projects analyzed continuously on the platform, therefore, with a
quality level above average (a priori)
The “Extra-Cockpit” projects: the projects reviewed from time to time on the platform in audit
mode, so with a highly heterogeneous quality.
Note: each project having its own specific quality profile, benchmarking does not take in account project
configuration, but uses instead raw measures.
The project is positioned relative to other projects according to the rate of violations for
each rule. The distribution is based on the quartile method, three groups are distinguished,
"Better": the 25% best projects, "On the average": the 50% average projects, "Worse": the 25%
worse projects. This information is then synthesized by level of severity.
The implementation rules compared are not necessarily the same as quality profiles, but
here we compare the rules according to their severity level set for each project.
The following graph provides the same analysis, but this time with the Intra-Cockpit projects, analyzed
continuously on the platform, so with a level of quality normally above average since detected violations
should be more corrected:
A dominant red color indicates that the other projects tend to correct the violations
detected on this project.
A similar comparison is provided for the cyclomatic complexity4 of methods, comparing the proportion of the
application (as a percentage of statements) that is located within complex methods:
A significant proportion of the application in the right area shows not only greater
maintenance and evolution costs, but also problems of reliability because this code is difficult to
test.
4
Cyclomatic complexity measures the complexity of the code, and thus its ability to test it,
cf.http://classes.cecs.ucf.edu/eel6883/berrios/notes/Paper%204%20(Complexity%20Measure).pdf
These models are built using the modeling wizard available in the Cockpit. You can modify these templates
on the pages Functional modelization et Technical Architecture (depending on your user rights).
The functional model is composed of modules, each one representing a business feature,
or a group of functionalities. These modules have been identified from a lexical corpus generated
from the application code which allows isolating the business vocabulary of the application.
Homogenize the behavior of an application. For example, to ensure that the logging traces are
written through a specific API, that data accesses pass through a dedicated layer, that some third-
party library is only used by specific components ...
Ensure tightness of some components to facilitate their development and limit unintended
consequences, but also make them shareable with other applications. Dependency cycles are for
instance forbidden.
Avoid security flaws for example by ensuring that calls to data layer always pass through a business
layer in charge of validation controls.
Green arrows formalize allowed communications between modules, while red arrows
formalize forbidden communications.
5 Detailed results
This chapter details the results by focusing, for each quality domain, non-compliant elements.
These rates of non-compliance directly depend on the quality profile and on the level of requirements that
have been selected:
Same class may be non-compliant on several factors, the total does not necessarily
correspond to the sum of the factors.
5.2 Implementation
Implementation domain covers the rules related to coding techniques. Unlike other domains, these rules are
often specific to the characteristics of a language (Java / C#). They identify, for example:
Implementations rules are the most numerous of the technical requirements. They are called "practice".
The following pie compares the number of non-compliant classes in implementation, according to the
practices that participated in this invalidation:
When a class only violates forbidden practices, it is in the group “Forbidden practices”
When a class only violates inadvisable practices, it is in the group “Inadvisable practices”
Otherwise, the class violates practices of both categories and is in the group “Inadvisable and
forbidden practices”
The effort of correction related to forbidden practices is generally less important compared
to lower severities: a single violation is sufficient to cause a forbidden non-compliance when
several inadvisable practices are needed to cause non-compliance, depending on tolerance
thresholds.
The table below completes the previous graph by introducing the concept of “Significant non-compliance”. A
significant violation is a violation whose correction can fix fully or partially the non-compliance of a class.
Indeed, due to tolerance thresholds associated with levels of severity, the correction of some violations has
no impact on the non-compliance of the class.
The columns "New non-compliance" and "Corrected non-compliances" are only relevant if
the audit follows a previous audit.
These tables provide for each practice the number of new non-compliances (if a previous audit has been
done), the total number of non-compliances for this practice, the number of non-compliant classes where
this practice has been detected and the percentage of statements of these classes compared to the overall
number of statement in the project.
These figures help to set up an action plan based on the impact associated with each practice.
For each class is associated the number of existing violations (forbidden or highly inadvisable practices), the
number of new violations (if a previous audit has been done), and the compliance status of the class.
5.3 Structure
The Structure domain targets rules related to the code structure, for example:
The objective is to ensure that the code is structured in such a way that it can be easily maintained, tested,
and can evolve.
These rules are “metric”. They measure values (e.g. A number of statements) and are conditioned by
thresholds (e.g. 100 statements / method). Only metrics on which developers are able to act are presented
here. They apply to all methods.
The percentage of statements shown is interesting since there is often only a few methods
concentrating a large part of the application code.
When some rules have been configured to be excluded from the analysis, they are
displayed in this graph but without any results.
One method may be affected by several rules; therefore, the total does not correspond to
the sum of numbers.
The following table completes this view by introducing the number of new violations and the number of
violations corrected in the case where a previous audit was conducted:
The last interval identifies the methods with a number of statements which exceeds the threshold. These
methods are considered non-compliant because they are generally difficult to maintain and extend, and also
show a high propensity to reveal bugs because they are difficult to test.
The percentage of statements is provided because larger methods usually focus a significant part of the
application:
The following table details the main non-compliant methods identified in the last interval of the previous
graph:
Cyclomatic complexity is a measure aiming to characterize the complexity of a block of code, by identifying
all possible execution paths. This concept has been standardized by Mc Cabe5, but several calculation
methods exist. The one used here is the most popular and the simplest: it counts the number of branching
operators (if, for, while,? ...) and conditions (??, && ...).
The last interval identifies methods whose complexity exceeds the threshold. These methods are considered
non-compliant for the same reasons as for the long methods: they are generally difficult to maintain and
extend, and also show a high propensity to reveal bugs.
The percentage of statements and the percentage of complexity are provided because the most complex
methods generally focus a significant part of the application.
5
1976, IEEE Transactions on Software Engineering: 308–320.
http://classes.cecs.ucf.edu/eel6883/berrios/notes/Paper%204%20(Complexity%20Measure).pdf.
The following table details the main non-compliant methods identified in the last interval of the previous
graph:
The principle is that a method with a strong efferent coupling is difficult to understand, maintain and test.
First because it requires knowledge of the different types it depends on, then because the risk of
destabilization is higher because of these dependencies.
This rule is crossed with the cyclomatic complexity to ignore some trivial methods, such as initialization
methods of graphical interfaces that make calls to many classes of widgets without presenting any real
complexity.
This rule considers that a method is non-compliant if it exceeds a threshold of efferent coupling and
threshold of cyclomatic complexity.
The chart below shows a mapping of methods according to their complexity and their efferent coupling. Each
dot represents one or more methods with the same values of complexity and coupling. They are divided into
four zones according to their status in relation to both thresholds:
The area on the lower left (green dots) contains compliant methods, below both thresholds
The area on the lower right (gray dots) contains compliant methods; they have reached the
complexity threshold, but remain below the coupling threshold
The area in the upper left (gray dots) contains compliant methods; they have reached the coupling
threshold, but remain below the complexity threshold
The area in the upper right (red dots) contains non-compliant methods; above both thresholds
The intensity of the color of the dots depends on the number of methods that share the
same values in complexity and coupling: the more the color of the point is marked, the more
involved methods.
The histogram below provides an additional view of this mapping and precise figures for the four zones in
terms of percentage of methods and statements of the application. The last bars indicate the area of non-
compliance:
5.4 Test
The Test domain provides rules to ensure that the application is sufficiently tested, quantitatively but also
qualitatively, i.e. tests should target risk areas.
5.4.1 Issues
It is important to situate the problems inherent in managing tests to understand the results of analysis for
this area.
A unit test is an automated test, which usually focus on a simple method inside source code. But
since this method has generally dependencies on other methods or classes, a unit test can test a
more or less important part of the application (the larger is this part, the less relevant is the test)
Code coverage measures the amount of code executed from tests, by identifying each element
actually executed at runtime (statements, conditional branches, methods ...). These tests can be
unit tests (automated) or integration tests / functional (manual or automated).
Code coverage is interesting to combine with the unit tests because it is the only way to measure the code
actually tested. However, many projects still do not check the code coverage, which does not allow verifying
the quality of testing in this type of analysis.
The indicators presented next address both cases; they are useful for projects with unit tests and/or code
coverage but also for other projects.
The problem is that these figures do not take into account the relevance to test the code. For example a
coverage of 70% of the application is a good figure, but the covered code could be trivial and without any
real interest for the tests (e.g. accessors or generated code), whereas the critical code may be located in the
remaining 30%.
The analysis performed here captures the relevance to test of each method, which is used to calibrate the
code coverage requirements and to set appropriate thresholds to better target testing effort towards risk
areas.
The TestRelevancyIndex (TRI) measures the relevancy of testing a method in accordance with its technical
risks and its business risk.
Technical risk assesses the probability of finding a defect; it is based on different metrics such as cyclomatic
complexity, number of variables, number of parameters, efferent coupling, cumulative number of non-
compliances...
The business risk associates a risk factor to business features which should be tested in priority (higher risk),
or instead which should not be tested (minor risk). It must be determined at the initialization of the audit to
be considered in the TRI calculations. The objective is to guide the testing effort on the important features.
For this, the TRI is used to classify the methods according to a scale of testing priority, and thus to distinguish
the truly relevant methods to test from trivial and irrelevant methods in this area. For each level of the scale,
a specific threshold to achieve with code coverage can be set. This allows setting a high threshold for critical
methods, and a low threshold for low-priority methods.
The TestEffortIndex (TEI) completes the TRI by measuring the level of effort required to test a method. Like
the TRI, it is based on a set of unit metrics characterizing a method. It helps to refine the decisions to select
the code to be tested by balancing the effort over the relevance test.
The details of calculating these two indexes are providing in annex (8.2 The coupling).
This mapping uses the code coverage information only if they were supplied for analysis. For each priority
level are indicated:
6
CETIC, Kalistick. Statistically Calibrated Indexes for Unit Test Relevancy and Unit Test Writing Effort, 2010
The table below shows these figures for each priority level, also adding a fifth level corresponding to the
methods without test priority:
A class can be green even if it is not or little tested: for example, classes with a low
probability of technical defects or without business risk. Conversely, a class already tested can be
stated as insufficient (red / brown) if its objective is very demanding.
An effective strategy to improve its coverage is to focus on large classes close to the goal.
The size of the class name depends on its relevancy in being tested (TRI cumulated for all methods of
this class)
The color represents the deviation from the coverage goal set for the class, just as in the previous
TreeMap
This representation identifies the critical elements, but if you want to take into account the
effort of writing tests, you must focus on the following representation to select items to be
corrected.
5.4.6 Most important classes to test and require the least effort (Quick Wins)
The “Quick Wins” complements “Top Risks” by taking into account the testing effort required for testing the
class (TEI):
The size of the class name depends on its interest in being tested (TRI), but weighted by the effort
required (TEI accumulated for all methods): a class with a high TRI and a high TEI (therefore difficult
to test) appears smaller than a class with an average TRI but a low TEI
The color represents the deviation from the coverage goal set for the class, just like the TreeMap or
QuickWin
The following table details the main methods to be tested first. Each method is associated with its current
coverage rate, the raw value of its TRI and its level of TEI:
5.5 Architecture
The Architecture domain aims to monitor compliance of a software architecture model. The target
architecture model has been presented in Chapter 4.3.2 Technical model. The following diagram shows the
results of architecture analysis by comparing this target model with current application code.
Currently, architecture non-compliances are not taken into account in the calculation of
non-compliance of the application.
5.6 Duplication
The Duplication domain is related to the “copy-and-paste” identified in the application. To avoid many false
positives in this area, a threshold is defined to ignore blocks with few statements.
Duplications should be avoided for several reasons: maintenance and changeability issues, testing costs, lack
of reliability...
Duplicates are categorized by ranges of duplicated statements. For each range is presented:
5.7 Documentation
The Documentation domain aims to control the level of technical documentation of the code. Only the
definition of standard comment header of the methods is verified: Javadoc for Java, XmlDoc for C#. Inline
comments (in the method bodies) are not evaluated because of the difficulty to verify their relevance (often
commented code or generated comments).
In addition, the header documentation is verified only for methods considered quite long and complex.
Because the effort to document trivial methods is rarely justified. For this, a threshold on the cyclomatic
complexity and a threshold on the number of statements are defined to filter out methods to check.
6 Action Plan
For each domain, a recommendation of corrections was established on the basis of tables detailing the rules
and code elements to correct. The following graph provides a comprehensive strategy to establish a plan of
corrections by defining a list of actions. This list is prioritized according to the expected return on
investment: the actions recommended in the first place are those with the best ratio between effort to
produce and gain on the overall rate of non-compliance.
5. Removing of duplications
This operation is more or less difficult depending on the case: you have first to determine whether
the duplication should really be factorized, because two components may share the same code base
but be independent. Note that the operation can be automated by some IDE and according to the
type of duplication.
The action plan can be refined on the Quality Cockpit using the mechanism of "tags." Tags
allow labeling the results of analysis to facilitate operations such as the prioritization of
corrections, their assignment to developers or the targeting of their fix version.
7 Glossary
Block coverage
Block coverage measures the rate of code blocks executed during testing compared to total blocks. A code
block is a code path with a single entry point, a single exit point and a set of statements executed in
sequence. It ends when it reaches a conditional statement, a function call, an exception, or a try / catch.
Branch coverage
Branch coverage measures the rate of branches executed during tests by the total number of branches.
if (value)
{
//
}
This code will be covered by branches to 100% if the if condition was tested in the case of true and false.
Line coverage
Lines (or statements) coverage measures the rate of executed lines during testing against the total number
of lines. This measure is insensitive to conditional statements, coverage of lines can reach 100% whereas all
conditions are not executed.
Line of code
A physical line of a source code in a text file. White line or comment line are counted in lines of code.
Non-compliance
A test result that does not satisfy the technical requirements defined for the project. Non-compliance is
related to a quality factor and a quality domain.
Quality domain
The test results are broken down into four areas depending on the technical origin of the non-compliances:
Quality factor
The test results are broken down into six quality factors following application needs in terms of quality:
Reliability: Does the application contain bugs that affect its expected behavior?
Maintainability: Do the maintenance updates require a constant development cost?
Security: Has the application security flaws?
Transferability: Is the transfer of the application towards a new development team a problem?
Statement
A statement is a primary code unit. For simplicity, a statement is delimited by a semicolon (;) or by a left
brace ({). Examples of statements in Java:
int i = 0;
if (i == 0) {
} else {}
public final class SomeClass
{
import com.project.SomeClass;
package com.project;
Unlike lines of code, statements do not include blank lines and comment lines. In addition, a line can contain
multiple statements.
8 Annex
Its high value is a sign that the source code will be hard to understand, to test, to validate, to maintain and to
evolve.
8.1.1 Definition
Imagine a control graph that represents the code that you want to measure the complexity. Then, count the
number of faces of the graph. This gives the structural complexity of the code, also called cyclomatic
complexity.
8.1.2 Example
We want to measure the complexity of the code:
int x = 3;
if (x > 0) {
x++;
} else {
x -;
7
: The S.E.I. (Software Engineering Institute, http://www.sei.cmu.edu/) is the institute at the origin of the CMMI
standar. Its researches on the quality of code make it a major and reliable actor in the domain. CMMi (Capability
Maturity Model Integration), is a process improvement approach that helps organizations improve their performance.
CMMI can be used to guide process improvement across a project, a division, or an entire organization. (source:
Wikipedia).
8.2.1 Definition
Two classes are coupled when methods declared in one use methods or instantiate variables defined in the
other. The relationship is symmetric: if class A is coupled to B, then B is coupled to A. The metric CBO
(Coupling Between Classes) measure for a given class A, the number of classes that are coupled to this class.
The efferent coupling measures for a given method, the number of references made to third types and their
methods in the method body. The higher the efferent coupling is, the more the method depends on other
classes.
The calculation of efferent coupling for a method is also straightforward, for example by counting:
Formal parameters (in the method signature) with a non-primitive type defined outside the class
throws declarations
Local variables of the method using a non-primitive type defined outside the class
8.3.1.1 Objective
The goal of TRI is to refine the analysis of code coverage performed by tests correlating the raw concept of
code coverage with relevance to test a method. The emphasis is no longer just the percentage of code
covered but also the relevance in the choice of tested methods. The interest is to ensure that the goal of
code coverage to reach will target appropriated methods.
8.3.1.2 Principle
TRI is an index specific to methods, whose value is obtained by scoring the values of some unitary metrics
(cyclomatic complexity, afferent coupling...) and applying a risk factor. This risk factor is associated with
business features the code element in implied with. Therefore risk factors are specific to the application.
Depending on the value of TRI, the methods are classified into five priority groups:
It is thus possible to specify for the critical elements a demanding test objective, handling different use cases,
and for lower priority items, define tests that target only nominal use cases.
8
CETIC, Kalistick. Statistically Calibrated Indexes for Unit Test Relevancy and Unit Test Writing Effort, 2010
8.3.2.1 Objective
TEI introduces a new dimension in the prioritization of test methods, providing an estimate of the effort
required to test a method.
This index is not implied in the non-compliance of methods, it is simply provided as a guide.
8.3.2.2 Principle
The TEI is an index specific to methods, whose value is obtained by scoring the values of some unit metrics
(cyclomatic complexity, number of parameters ...). Based on this TEI value, the methods are classified into
five groups of test effort:
DontDefineHardwiredDBP The password for logging into the database should not be Forbidden
assword
hardcoded in the Java code.
DontDefineHardwiredPath Hard-coded file paths are prohibited. Forbidden
Names
DontDefineTooManyLevel It is very difficult to understand a design when there are many Forbidden
sOfNestedInnerClasses
internal nested classes
DontHideInheritedInstance When a class inherits from another class, you must make sure that Forbidden
Fields
you don't hide the fields belonging to the parent class, because
this can have disastrous side-effects.
DontInstantiateStringBuffer Don't instantiate a StringBuffer with a char argument because the Forbidden
WithChar
constructor is used to initialize the size of the StringBuffer.
DontOverloadFinalize It is inadvisable to redefine the finalize() method with parameters. Forbidden
This method will not be called by the JVM and could be a source of
confusion and errors.
DontOverwriteNonReadPa You should not write to parameters which are never read. Forbidden
rameter
DontPutRandomResultInIn The result of the random operation must not be stored as an Forbidden
teger
integer
DontSynchronizeOnBoole Don't synchronize on a Boolean object. Otherwise, it can cause Forbidden
an
thread deadlocks.
DontSynchronizeOnBoxed Don't synchronize on a primitive Wrapper object as an integer, for Forbidden
Primative
example. Otherwise, it can cause thread deadlocks.
DontSynchronizeOnConst Don't synchronize on a String constant. Otherwise, it can cause Forbidden
antString
thread deadlocks.
DontUseAssertAsIdentifier The word 'assert' must not be used as an identifier because it has Forbidden
been a reserved word since Java 5.
DontUseConstructorsInClo Clone must not use a constructor Forbidden
neMethod
DontUseDirectlyParameter Don't write HTTP parameters directly into a cookie that will be Forbidden
InCookieResponse
returned to the client browser.
DontUseDirectlyParameter Don't write HTTP parameters directly into the HTTP header Forbidden
InHeaderResponse
response.
DontUseDirectlyParameter Don't write HTTP parameters directly into the Servlet output Forbidden
InServletWriter
(cross-site scripting vulnerability).
DontUseEnumAsIdentifier Enum must not be used as an identifier for reasons of portability Forbidden
to Java 5 and above
DontUseEqualsOnFloats Comparisons of floating-point numbers may be inaccurate. Forbidden
DontUseMultipleUnaryOpe Writing multiple unary operators together creates complex code. Forbidden
rators
DontUseNewToInstantiateI Creation of an Integer object from a primitive integer must be Forbidden
ntegers
done using the valueOf() method rather than the constructor.
DontUseNewToInstantiate Instantiation of new String objects is generally pointless, String Forbidden
Strings
objects aredirectly initialised from character strings.
DontUseNonCaseLabelInS The use of label statements during development is recognized as Forbidden
witch
being a bad way of coding.
DontUseOctalNotation Don't assign an Octal value (integer beginning with 0) to an Forbidden
integer.
DontUseReturnInFinallyBl Use of the return instruction in a finally block is prohibited. Forbidden
ock
DontUseSameVariableLoo The same loop variable must not be incremented for two nested Forbidden
pAsEnclosingLoop
'for' loops
ImpossibleCast Cast which always returns <code>ClassCastException</code> Forbidden
InfiniteLoop Infinite loops are an inadvisable practice in a Java environment. Forbidden
AlwaysMakeInitializersStat
It is inadvisable to initialise attributes in non-static blocks and Highly
ic
outside methods inadvisable
AlwaysProvideThrowClone A non-cloneable class must always return Highly
NotSupportedExceptionFo
rCloneMethod
<code>CloneNotSupportedException</code> inadvisable
DontAssignVariablesInOpePerforming assignments within conditions or within operations Highly
rands
complicates reading the code inadvisable
DontCallNextInHasNextMe <code>Next</code> must never be called within a Highly
thod
<code>hasNext</code> method. inadvisable
DontCallSystemExit Calls to the <code>System.exit()</code> method are rarely Highly
justifiable. inadvisable
DontIgnoreInputstreamRe It is essential to check the return from the methods Highly
adReturnValue
<code>read(byte[])</code> and <code>read(byte[] b int, inadvisable
int)</code> to use the resulting array.
DontIgnoreMethodsReturn Return values of methods should be used. Highly
Value
inadvisable
DontMakeAssignmentInRe Don't assign a variable in a return statement. Highly
turnStatement
inadvisable
DontMakeClassesFieldsPu Class attributes must not be declared with public visibility, unless Highly
blicExceptFinalFields
they are final or static. inadvisable
DontStartThreadInsideCtor Starting a thread within a class constructor is a risky practice. Highly
inadvisable
DontThrowNPE Explicitly throwing a <code>NullPointerException</code> can Highly
cause confusion. inadvisable
DontTouchForLoopVariabl Be careful not to modify the iteration variable of a for loop within Highly
e
the loop. inadvisable
DontUseExceptionAsGoto We recommend that you do not use exceptions to control the flow Highly
of a method, throwing an exception to catch it a few lines later. inadvisable
DontUseInstanceofInCatch Different types of exception must be caught in different catch Highly
Blocks
blocks, not by manually testing the type of each exception. inadvisable
NeverMakeCtorCallInnerM A constructor must never call an internal method Highly
ethod
inadvisable
OverrideEqualsAndHashc If one of the two methods <code>equals()</code> or Highly
odeTogether
<code>hashCode()</code> must be overloaded, it is necessary to inadvisable
overload the other one.
OverrideEqualsWhenImple Implementation of <code>compareTo()</code> also assumes Highly
mentingCompareTo
implementation of <code>equals()</code> inadvisable
ThreadsMustHaveRunMet A class deriving from <code>Thread</code> or implementing Highly
hod
<code>Runnable</code> must implement the inadvisable
<code>run()</code> method.
TraceErrorsWithLogger We recommend that you log errors using a logging API rather than Highly
making calls to <code>printStackTrace()</code>. inadvisable
UseBetterInterfaceIterator We recommend that you use the interfaces in the collections Highly
framework (<code>Iterator</code>) as replacements for inadvisable
<code>Enum</code>.
UseConstantStringsForSql For security reasons, SQL requests must have a consistent Highly
Requests
structure inadvisable
UseLoggerRatherThanPrin It is preferable to use a logging framework rather than directly Highly
tMethods
writing to the standard output or the error output. inadvisable
UseStaticFinalLoggerForCl An attribute of the logger type must generally be declared as Highly
assesThatNeedOne
static. inadvisable
DontDirectlyReturnArray When a method returns an object attribute which is of the array To be avoided
type, it is preferable to return a copy of the array rather than the
direct reference.
DontDirectlyStoreArray Directly storing an array received as a parameter in an attribute To be avoided
does not keep exclusive control of the attribute because it still
remains modifiable by other classes.
DontLeaveEmptyFinallyBlo A finally block must not be left empty. To be avoided
cks
DontLeaveEmptyInitializer
Empty static initialisation blocks must be deleted. To be avoided
DontLeaveEmptyLoops Loops must never be left empty. To be avoided
DontLeaveEmptyMethods Empty methods must be commented. To be avoided
DontLeaveEmptySynchron A synchronised block must never be empty To be avoided
izedBlocks
DontLeaveEmptyTryBlock A try block must never be empty To be avoided
s
DontLeaveUnusedLocalVa Local variables must never be left unused To be avoided
riables
DontLeaveUnusedPrivateF Private attributes which are not used in classes must be deleted. To be avoided
ields
DontLeaveUnusedPrivate Private methods which are not used in classes must be deleted. To be avoided
Methods
DontNestTooManyConditio You should avoid using too many nested if structures To be avoided
nnalStatements
DontUseForWithoutUpdate Typically, within a for loop, there is an update condition To be avoided
Clause
DontUseInstanceToAcces Static methods and fields must be accessed through the class, not To be avoided
sStaticFieldsOrMethods
through an instance.
DontUsePollingLoops The use of the wait instruction is much more efficient than a test To be avoided
loop
DontUseProtectedFieldsIn As classes cannot be derived from final classes, use of the To be avoided
FinalClasses
protected keyword is pointless
DontUseTooLongDotChain Do not use chains of methods within a single instruction. To be avoided
CallsInOneStatement
ReturnEmptyArrayRatherT It is preferable to return an empty array rather than the value To be avoided
hanNull
<code>null</code>
SwitchCaseMustHaveDefa A switch instruction should always contain the To be avoided
ultStatement
<code>default</code> block.
UselessConsecutiveLiteral It is preferable to group several calls to To be avoided
Appends
<code>StringBuffer.append()</code> into a single call when
constant strings are added.
DontLeaveEmptyCtor When a constructor is empty, it is preferable to insert a comment [None]
to justify its definition.
DontLeaveUnusedImpo Needless import lines should be deleted. [None]
rts
UseBetterObjectCollecti It is preferable to use optimised <code>Collection</code> objects [None]
on rather than arrays of objects.