Style Guide (Checkstyle)¶
Source: https://xkcd.com/1513/
Background¶
Virtually every organization that does software development has strict guidelines on how to format source code. Here are two examples of "industrial strength" Java style guides:
This course will follow a simplified version of these guidelines. We hope you will focus on developing good habits and intuition about style, rather than memorizing a long list of rules.
Source: https://checkstyle.sourceforge.io/
Checkstyle is a tool (integrated into VS Code) that can be used to determine if your source code follows a set of style rules. Checkstyle also checks for common programming mistakes, such as empty statements and accidental assignment.
A. Comments¶
- Every class must contain a Javadoc comment with the following three elements.
/**
* Overall description of the class goes here.
*
* @author Your name goes here
* @version Due date goes here
*/
- All methods (including
main
) must contain an applicable Javadoc comment.
/**
* Overall description of the method goes here.
*
* @param parameterName describe each input parameter
* @param anotherParam use a separate line for each
* @return describe the value that this method returns
*/
-
In-line comments (
//
) should describe major structures and steps within a method. -
All comments should use normal English spelling and grammar. Phrases are okay.
-
Comments must come before the code that they are describing or on the same line.
B. Names¶
-
All names should be descriptive and readable.
(subTotal
rather thans
,grade
rather thangrd
) -
Multiple-word names should use capital letters to separate words.
(subTotal
, notsub_total
) -
Variable and method names should begin with a lowercase letter, and:
-
Variable names should be nouns or noun phrases.
(studentName
orsubTotal
) -
Method names should be verbs or verb phrases.
(printLine
oraddColumn
)
-
-
Class names should begin with a capital letter and use title case.
(HelloWorld
) -
Constant names should be all caps with an underscore separator.
(PI
orINTEREST_RATE
)
C. Declarations¶
-
All constants should be named and initialized at the top of the method in which they are used.
final double CENTIMETERS_PER_INCH = 2.54; centimeters = inches * CENTIMETERS_PER_INCH; // NOT inches * 2.54;
-
All variables should also be declared at the top of the method, directly after any constant declarations.
-
It is recommended (in CS 159) to separate variable declaration and initialization statements.
Scanner input = new Scanner(System.in); // discouraged Scanner input; input = new Scanner(System.in);
-
Each declaration should be on its own line. Comment to the right if the name is not self-explanatory.
D. Literals¶
- Numeric literals should be of the correct type for the context in which they are used.
// integer expressions should use integer literals
int a;
double b;
a = 2;
b = 2.0;
// double expressions should use double literals
double x;
double y;
double average;
average = (x + y) / 2.0; // NOT 2, which is an integer
E. Indentation¶
-
Subsections of code should be indented consistently with four spaces.
-
Always use four space characters, not tab characters, for indentation.
-
Statements too long for one line should be indented on subsequent lines.
-
All blocks of code (even if one line) should be surrounded by curly braces.
-
Left braces must appear at the end of the same line as the structure header.
F. Whitespace¶
-
There should be a space after cast operators, commas, and
//
's. -
Use whitespace to separate logical segments of code. There should be a blank line after variable declarations.
-
Lines should be kept to a short length (< 80 chars). You should be able to see the full line in your text editor.
-
Binary operators should be separated from their operands by a single space.
(sum = myGrade + yourGrade;
) -
The dot (
.
) operator, on the other hand, should not have any space surrounding it.
(System.out.println();
) -
Unary operators should also not be separated by a space.
(myGrade++;
)