Checkstyle
Checkstyle is a tool for checking Java source code for adherence to the Google Java Style Guide.
Click “checkstyle” to view the report. The report should look like this:
You can access each code line violating the coding standard through “Findings(6)”
The following is some comments you might find in the report:
The name of the outer type and the file do not match. (com.puppycrawl.tools.checkstyle.checks.OuterTypeFilenameCheck)
This is a compilation error where filename is different from class name. Your class name must always be the same with the filename. If you class name is Main, then the filename must be Main.java.
Missing a Javadoc comment.
There is a special format for Javadoc if you want to put comments above a method.
Javadoc comment is placed in the wrong location.
Class level Javadoc should be after the import section and before class.
Example of bad Javadoc:
Example of good Javadoc:
Forbidden summary fragment.
It means CheckStyle detects “the method returns” in the Javadoc. The return information should be in a @return tag.
The @return tag is required for every method that returns something other than void, even if it is redundant with the method description.
‘CLASS_DEF’ should be separated from previous statement.
‘METHOD_DEF’ should be separated from previous line.
There should be some space between classes and methods for readability.
‘method def modifier’ has incorrect indentation level 4, expected level should be 2.
Checkstyle uses an indentation of 2 spaces, but most IDEs use 4 spaced indentation. Therefore, if you want to use 4 spaced indentation, you can ignore this comment.
Line contains a tab character.
This mean your code line contains a tab character.
Using the tab key inserts an actual invisible tab character into your text, which can mess up the formatting later when your publisher tries to reformat your document for publication.
Different IDEs have different size of tab. Tab character is commonly 2 or 4 spaces in most IDEs. The differences can cause inconsistent code style while copying and pasting code. Therefore, programmers should use spaces instead of tab charater.
Line is longer than 100 characters (found 109).
A normal computer screen cannot show more than 100 characters horizontally, preferably under 80 character. The long line should be broken into shorter lines to ensure readability.
Local variable name ‘Codingstyle’ must match pattern ‘^[a-z]([a-z0-9][a-zA-Z0-9]*)?$’
The first letter of variable name should be in lowercase, and each new word start with a uppercase letter.
Abbreviation in name ‘SML’ must contain no more than ‘2’ consecutive capital letters.
The variable name rule is the first letter should be in lowercase, and each new word start with a uppercase letter. Therefore, each uppercase letter will be counted as a word. 3 consecutive capital letters mean 3 words next to each other. The name is too short and and undescriptive.
Method name ‘ToString’ must match pattern ‘^[a-z][a-z0-9][a-zA-Z0-9_]*$’.
The first letter of method name should be in lowercase, and each new word start with a uppercase letter.
Only one statement per line allowed.
Code should only have 1 statement per line for readability.
‘if’ construct must use ‘{}’s.
Even when you only have 1 statement in your constructor, you should uses ‘{}’. For example:
’{‘ at column 5 should be on the previous line.
CheckStyle follows K&R style that { is in the same line with the control statement (if, while, for…). If you want to use Allman or other styles, you can ignore this warning.
WhitespaceAround: ‘=’ is not preceded with whitespace and WhitespaceAround: ‘=’ is not followed by whitespace. Empty blocks may only be represented as {} when not part of a multi-block statement (4.1.3).
There should be a space before and after all operators (+, -, *, /, =, <, >, &&, ||, !=, >=, <=, ==).
; should be followed by a space if there is anything after it
’(‘ is preceded with whitespace.
There should be no spaces before the parentheses in a method call or a constructor creation.
’(‘ is followed by whitespace.
There should be no spaces after ( and before ).
’}’ at column 9 should be on the same line as the next part of a multi-block statement (one that directly contains multiple blocks: if/else-if/else, do/while or try/catch/finally).
CheckStyle follows K&R style that if you have multiple if-else statements, the next one should be on the same line with the previous ending bracket ‘}’
If you want to use Horstmann or other styles, you can ignore this warning.
Using the ‘.*’ form of import should be avoided - java.util. * .
The library is divided into packages and classes. Meaning you can either import a single class (along with its methods and attributes), or a whole package that contain all the classes that belong to the specified package.
You should import specific classes that are used in the program instead of import the whole package
Wrong lexicographical order for ‘java.util.Array’ import. Should be before ‘java.util.Scanner’.
The import should be in lexicographical order (alphabetical order A-Z). For example, io shoud be before util and Array should be before Scanner. The following is an example of import section in correct lexicographical order.
Extra separation in import group before ‘java.util.Array’
There should be no separation (new lines) within the import section.
Array brackets at illegal position.
Brackets should be put right after the declaration type, not the name.
Distance between variable ‘size’ declaration and its first usage is 5, but allowed 3. Consider making that variable final if you still need to store its value in advance (before method calls that might have side effects on the original value).
size and 5 can be different based on developer’s code.
When a variable is initilized, you should use it within the next 3 code lines. It helps to group related codes together and make them easier to read.
New Warnings
If you don’t see your warnings on the website, please fill this survey so that we can add them: New CheckStyle Warning