Check and feel better about your code!

(c) 1999-2005 by Ralph Jocham (rjocham72@netscape.net)
JCSC is released under the terms of the GNU General Public License




How to get


Remote Tools

SourceForge Logo



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


  • 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


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