2.1 Eclipse

If you are using Eclipse then you can install the Checkstyle plugin and use Checkstyle from within Eclipse. After you have installed and enabled the plugin, load the "checks file" discussed above.

You can also have Eclipse automatically format your code. To do so, download the following formatter:

and then, in Eclipse, click on Window+Preferences+Java+Code Style+Formatter+Import.

2.2 jGRASP

jGRASP supports Checkstyle as one of its "Tools". After you download the .jar file and the checks file (see above), you need to configure it so that the "Checkstyle home directory" points to the directory/folder containing the Checkstyle .jar file (by clicking on Browse) and the "Checks file" points to the checks file you downloaded (again, by clicking on Browse).

2.3 NetBeans

If you are using NetBeans then you can install the Checkstyle plugin and use Checkstyle from within Eclipse. After you have installed and enabled the plugin, load the checks file discussed above.

2.4 Other IDEs

Many other IDEs also provide support for Checkstyle. A quick search of the WWW should help you get started.

3.1 Organization/Structure

1. Each class must be in its own file.

   The name of the file and the name of the class must coincide exactly. For example the Queue class should be in a file named Queue.java. Note that Java is case-sensitive (even though some versions of MS-Windows are not).

2. Each file must end with a blank line.

   This is so that automated testing tools have a place to insert comments/remarks if necessary.

3. Methods within a class must be listed in alphabetical order.

   The only exception to this rule is that all constructors must be listed first. For example, in a Queue class, the constructor(s) should be first, the pop method should be second, and the push method should be third.

   javaexamples/Queue.java

4. All variables must be declared at the top of the relevant class or method (with two exceptions).

   So, class/instance variables should be declared at the top of the class (before any methods are declared) and variables that are local to a method should be declared at the top of that method (before any other lines of code). The only exceptions to this rule are:

   In the constructor of a derived class the call to the constructor of the parent class must come first.

   Index variables in loops may be declared locally.

5. Class variables (i.e., static attributes) must be declared before instance variables (i.e., non-static attributes).
6. All variables must be declared alphabetically by their class/type.

   For example, variables of type double should be declared before variables of type int which should, in turn, be declared before variables of type Node.

3.2 Names

1. Class names must start with an uppercase letter.

   In addition, each "word" within a class name should start with an uppercase letter. For example, TextMessage and SimpleTrafficMonitor are both appropriate class names.

2. The names of "constants" (i.e., static final attributes) must be in all uppercase.

   Further, "words" within a "constant" name must be delimited by an underscore character. For example, EXTREMELY_UNHEALTHY is an appropriate name for a "constant".

3. The names of final variables (including formal parameters) must not include any underscore characters.
4. Other variable and method names that contain multiple characters must not start with an uppercase letter.

   Further, each "word" within a variable name should start with an uppercase letter. For example, importantMessage and campusMonitor are both appropriate variable names.

5. Variable names that consist of a single character may be uppercase.

   In general, even single-character variable names should be lowercase. However, in some situations, mathematical notation uses uppercase letters. In such situations, uppercase variable names may be used. For example, matrices are often written using uppercase letters. So, an expression like (b = A*x) would be appropriate.

6. Variable and method/function names must be descriptive.

   Variable names like aaa are not appropriate. Index variables and counters can, however, have names like i and j.

3.3 Declarations

1. Variables (other than index variables in loops) must not be declared and initialized in a single statement.

   For example, you must not have statements like int i = 0;. (Though this is inconvenient in some situations, it prevents a common mistake made by beginning programmers.)

2. Visibility modifiers must be explicit.

   Do not rely on default visibilities.

3. All (non-final) attributes should have private or protected visibility.

   Indeed, they must have private or protected visibility unless there is a very good reason for them to have public or package visibility.

3.4 Comments

1. Each class must have a descriptive block comment.

   This comment should describe the complete class (rather than the methods in the class).

2. Each method/function must have a descriptive block comment.

   This comment should describe the methods, its parameters, and its return value.

3. Block comments must use the javadoc format.

   javadoc is a program (written in Java) that creates external documentation (in HTML) from block comments. All of the Java documentation was, in fact, created this way. javadoc block comments start with /** and end with */.

   javaexamples/JavadocExample.java

4. Comments in the body of a class should use // rather than /* ... */.

   This isn't a requirement but it will make your life easier since you can't nest block comments. There is nothing more annoying then trying to "comment out" a section of code while you are debugging and being unable to do so because it contains block comments.

5. In the block comment for each class you must include a comment attesting to your compliance with the JMU Honor Code as follows:

   	 *
   	 * This work complies with the JMU Honor Code.
   	 *
            

6. In the block comment for each class you must include an @author element.

3.5 White Space

1. Lines must be short (i.e., less than 100 characters).
2. With the exception of the . operator, operators must be separated from their operands by one space.
3. Unary operators must not be separated from their operands by any white space.

3.6 Indentation and Blocks

1. Four spaces must be used for each indentation level.
2. All blocks of code (even if one line) must be surrounded by { and }.
3. The { must appear on a new line at the start of the block.
4. Empty blocks are prohibited.
5. Do not have multiple clauses on a single line in switch statements.
   

           // The correct style for a switch statement
           //
           switch (seatLocationCode)
           {
               case 100: 
                   vip   = true;
                   price = 40.0;
                   break;
                   
               case 200:
                   price = 30.0;
                   break;
                   
               case 300:
                   price = 15.0;
                   break;
                   
               default:
                   price = 0.0;
                   break;
           }