 JCSC
Documentation
Extensions
How
to get
General
Remote Tools
Friends
|
|
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)
- Constructor Declaration
- 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
 |
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)
|
|
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
|
