JCSC

Overview

JCSC is a powerful tool to check source code against a highly definable coding standard and potential bad code.
The standard covers naming conventions for class, interfaces, fields, parameter, ... . Also the structural layout of the type (class/interface) can be defined. Like where to place fields, either before or after the methods and in which order. The order can be defined through the visibility or by type (instance, class, constant). The same is applicable for methods. Each of those rules is highly customizable. Readability is enhanced by defining where to put white spaces in the code and when to use braces. The existence of correct JavaDoc can be enforced and various levels. Apart from that, it finds weaknesses in the the code -- potential bugs -- like empty catch/finally block, switch without default, throwing of type 'Exception', slow code, ... . JCSC is inspired by lint.

JCSC features a graphical UI for easy rule configuration, a command line interface, an Ant task which produces a JavaDoc style webpage and is CruiseControl compatible (see screenshot). Also, the NCSS/CCN metrics have been added for easier code quality assesment. Plugin for IntelliJ IDEA enables ad hoc checking from within the IDE. (see screenshot)

Currently JCSC supports over 100 enforceable rules -- this is not all and there is more to come!

NEW: Full support of the JDK 1.5 (Java 5) language. The rules editor is now a web start application; see Remote Tools or click here JCSC Web Start.

Tested platforms: Windows (with and without cygwin), Linux, Mac OS X

Performed Checks in a Nutshell

The default checking rules adhere to the Sun Code Conventions with some additional auditing for weak code. (see Sun Code Conventions for the Java Programming Language)

Each of those checks can be either switched on/off, or be configured (see Rules)

General Checks

correct class/interface header
line length
NCCS (non commenting source statements = real code) count for class
NCSS checking for method length
CCN (cyclomatic complexity number) checking for methods
tabulators in source code allowed
.* imports allowed or use fully qualified imports
only catch subclassed exceptions; not Throwable and Exception
check declaration modifier order (also in nested classes)
interface are not declared abstract
'l' for long values allowed ('l' if often mistaken for '1' -> use 'L'; i.e. 40l or 40L)
space after statement (if, else, while, ...)
throwing of 'Exception' or only of subclasses types allowed
only catching of specialized Exeptions (not Throwable, Exception) is allowed
switch statement requires default
assignments in conditional expressions allowed (if (a = 5))
allow 'get' prefix for method returning a boolean or enforce 'is', 'has', 'are' instead
allow type 'Vector' to be returned, use 'List' or 'Collection' instead; new faster Collection API
allow type 'Hashtable' to be returned, use 'HashMap' instead; new faster Collection API
allow String literals or only constants (final static String) in code. Important for internationalization
empty catch block allowed or indicated
empty finally block allowed or indicated
complex loop expression allowed or customizable
conditional expression allowed or indicated
number of arguments of method calls; too many arguments indicate procedural programming
semicolon after type declaration allowed (this is C++)
single line block without '{', '}' allowed (if, else, ...)
Array specifier at type (ie. String[] names and not String names[])
allow public, protected or package private fields
only one declaration per line
allow public fields or not
check [] at type and not at field name
indicate when too many parameters are passed
...

Naming Checks using regexps for

package
class
interface
abstract class
label
instance field (separate regexps for different visibility)
class (static) field (separate regexps for different visibility)
constant (final static) field (separate regexps for different visibility)
local variables
instance method name (separate regexps for different visibility)
class (static) method name (separate regexps for different visibility)
final method name (separate regexps for different visibility)
final class (static) method name (separate regexps for different visibility)
argument
final argument
...

Placing Rule Checks for method, fields and inner classes in class/interface

Fields before/after methods
Method order
- no order
- by visibility; public->protected->package private->private or vice versa
- by type; constructor->static->instance or any other permutation of the three
Field order
- no order
- by visibility; public->protected->package private->private or vice versa
- by type; static final->static->instance
Inner classes/interface at end or beginning of class

JavaDoc Checking for

Each of the JavaDoc rules can be customized for different visiblities
Type Delcaration (class/interface)

@author
@version

Constructor Declaration

@param
@throws

Method Declaration

@param
@throws
@return (considers void methods)
switch JavaDoc checking on/off for anonymous inner classes

Field Declaration
Correct order of JavaDoc Tags

Metrics

NCSS (non commenting source statements- real code) are being calculated for the whole project, individual classes and methods
CNN (cyclomatic complexity number - possible number of pathes through a method) are generated for all methods and constructiors

Testimonials

www.valtech.com As a consultant with an agile approach who often works in regulated environments I find using JCSC under CruiseControl to be invaluable tool for both managing code quality and providing an audit trail of compliance to standards.

Keith Thomas, Consultant Valtech (Keith.Thomas@valtech.com)

Thinking in Java 3rd ed.
Bruce Eckel used JCSC to validate the code examples in his 3rd edition of Thinking in Java
See B: Java Programming Guidlines / Implementation

Last updated on 2003年07月03日 18:34