Checkstyle Integration: New Codacy Feature

In this article:
Subscribe to our blog:

Checkstyle is one of the best and most comprehensive static analysis tools for Java code.

We’re happy to announce that Checkstyle rules are now supported on Codacy (and since Checkstyle was already using Codacy, it is now a bi-lateral relationship).

Some of the rules were already in Codacy, but a lot weren’t; this brings Codacy’s Java patterns up to 379, covering code style, compatibility, error-proneness, performance, security and unused code.

Codacy also checks for duplication of Java code and you can add coverage to your repo.

Since there are several coding styles for Java, we currently don’t enforce any of them, so none of these patterns are currently enabled by default; we’ll be adding a few bundles so you can select some sets of rules.

Here is a list of the new rules:

  • AbbreviationAsWordInName — The Check validate abbreviations(consecutive capital letters) length in identifier name, it also allow in enforce camel case naming
  • AnnotationLocation — Check location of annotation on language elements
  • AnnotationUseStyle — This check controls the style with the usage of annotations
  • AnonInnerLength — Checks for long anonymous inner classes
  • ArrayTrailingComma — Checks if array initialization contains optional trailing comma
  • ArrayTypeStyle — Checks the style of array type definitions
  • AtclauseOrder — Checks the order of at-clauses
  • AvoidEscapedUnicodeCharacters — Restrict using Unicode escapes
  • AvoidInlineConditionals — Detects inline conditionals
  • AvoidNestedBlocks — Finds nested blocks
  • AvoidStarImport — Check that finds import statements that use the * notation
  • AvoidStaticImport — Check that finds static imports
  • BooleanExpressionComplexity — Restricts nested boolean operators (&&, ||, &, | and ^) to a specified depth
  • CatchParameterName — Checks that catch parameter names conform to a format specified by the format property
  • ClassDataAbstractionCoupling — This metric measures the number of instantiations of other classes within the given class
  • ClassFanOutComplexity — The number of other classes a given class relies on
  • ClassTypeParameterName — Checks that class type parameter names conform to a format specified by the format property
  • CommentsIndentation — Controls the indentation between comments and surrounding code
  • CovariantEquals — Checks that if a class defines a covariant method equals, then it defines method equals(java.lang.Object)
  • CustomImportOrder — Checks that the groups of import declarations appear in the order specified by the user
  • DeclarationOrder — Checks that the parts of a class or interface declaration appear in the order suggested by the Code Conventions for the Java Programming Language
  • DescendantToken — Checks for restricted tokens beneath other tokens
  • DesignForExtension — Checks that classes are designed for inheritance
  • EmptyBlock — Checks for empty blocks
  • EmptyForInitializerPad — Checks the padding of an empty for initializer; that is whether a space is required at an empty for initializer, or such spaces are forbidden
  • EmptyForIteratorPad — Checks the padding of an empty for iterator; that is whether a space is required at an empty for iterator, or such spaces are forbidden
  • EmptyLineSeparator — Checks for blank line separators
  • EmptyStatement — Detects empty statements (standalone ‘;’)
  • ExecutableStatementCount — Restricts the number of executable statements to a specified limit (default = 30)
  • ExplicitInitialization — Checks if any class or object member explicitly initialized to default for its type value (null for object references, zero for numeric types and char and false for boolean
  • FileLength — Checks for long source files
  • FileTabCharacter — Checks to see if a file contains a tab character
  • FinalClass — Checks that class which has only private constructors is declared as final
  • FinalParameters — Check that method/constructor/catch/foreach parameters are final
  • GenericWhitespace — Checks that the whitespace around the Generic tokens < and > are correct to the typical convention
  • Header — Checks the header of the source against a fixed header file
  • HiddenField — Checks that a local variable or a parameter does not shadow a field that is defined in the same class
  • HideUtilityClassConstructor — Make sure that utility classes (classes that contain only static methods) do not have a public constructor
  • IllegalImport — Checks for imports from a set of illegal packages
  • IllegalInstantiation — Checks for illegal instantiations where a factory method is preferred
  • IllegalThrows — Throwing java.lang.Error or java.lang.RuntimeException is almost never acceptable
  • IllegalToken — Checks for illegal tokens
  • IllegalTokenText — Checks for illegal token text
  • IllegalType — Checks that particular class are never used as types in variable declarations, return values or parameters
  • ImportControl — Check that controls what packages can be imported in each package
  • ImportOrder — Ensures that groups of imports come in a specific order
  • Indentation — Checks correct indentation
  • InnerAssignment — Checks for assignments in subexpressions, such as in String s = Integer.toString(i = 2);
  • InnerTypeLast — Check nested (internal) classes/interfaces are declared at the bottom of the class after all method and field declarations
  • InterfaceTypeParameterName — Checks that interface type parameter names conform to a format specified by the format property
  • JavaNCSS — This check calculates the Non Commenting Source Statements (NCSS) metric for Java source files and methods
  • JavadocMethod — Checks the Javadoc of a method or constructor
  • JavadocPackage — Checks that all packages have a package documentation
  • JavadocTagContinuationIndentation — Checks the indentation of the continuation lines in at-clauses
  • JavadocParagraph — Checks Javadoc paragraphs
  • JavadocStyle — Custom Checkstyle Check to validate Javadoc
  • JavadocType — Checks the Javadoc of a type
  • JavadocVariable — Checks that a variable has Javadoc comment
  • LeftCurly — Checks the placement of left curly braces on types, methods and other blocks:
  • LineLength — Checks for long lines
  • LocalFinalVariableName — Checks that local final variable names conform to a format specified by the format property
  • LocalVariableName — Checks that local, non-final variable names conform to a format specified by the format property
  • MagicNumber — Checks for magic numbers
  • MemberName — Checks that instance variable names conform to a format specified by the format property
  • MethodCount — Checks the number of methods declared in each type
  • MethodParamPad — Checks the padding between the identifier of a method definition, constructor definition, method call, or constructor invocation; and the left parenthesis of the parameter list
  • MethodTypeParameterName — Checks that class type parameter names conform to a format specified by the format property
  • MissingCtor — Checks that classes (except abstract one) define a ctor and don’t rely on the default one
  • MissingDeprecated — This class is used to verify that both the java.lang.Deprecated annotation is present and the @deprecated Javadoc tag is present when either is present
  • MissingOverride — This class is used to verify that the java.lang.Override annotation is present when the {@inheritDoc} javadoc tag is present
  • ModifiedControlVariable — Check for ensuring that for loop control variables are not modified inside the for block
  • ModifierOrder — Checks that the order of modifiers conforms to the suggestions in the Java Language specification, sections 8.1.1, 8.3.1 and 8.4.3
  • MultipleStringLiterals — Checks for multiple occurrences of the same string literal within a single file
  • MultipleVariableDeclarations — Checks that each variable declaration is in its own statement and on its own line
  • MutableException — Ensures that exceptions (defined as any class name conforming to some regular expression) are immutable
  • NeedBraces — Checks for braces around code blocks
  • NestedForDepth — Restricts nested for blocks to a specified depth (default = 1)
  • NestedIfDepth — Restricts nested if-else blocks to a specified depth (default = 1)
  • NestedTryDepth — Restricts nested try-catch-finally blocks to a specified depth (default = 1)
  • NewlineAtEndOfFile — Checks that there is a newline at the end of each file
  • NoFinalizer — Checks that no method having zero parameters is defined using the name finalize
  • NonEmptyAtclauseDescription — Checks that the at-clause tag is followed by description
  • NoLineWrap — Checks that chosen statements are not line-wrapped
  • NoWhitespaceAfter — Checks that there is no whitespace after a token
  • NoWhitespaceBefore — Checks that there is no whitespace before a token
  • OneStatementPerLine — Checks that there is only one statement per line
  • OneTopLevelClass — Checks that each top-level class, interfaces or enum resides in a source file of its own
  • OperatorWrap — Checks line wrapping for operators
  • OuterTypeFilename — Checks that the outer type name and the file name match
  • OuterTypeNumber — Checks for the number of defined types at the
  • OverloadMethodsDeclarationOrder — Checks that overload methods are grouped together
  • PackageAnnotation — This check makes sure that all package annotations are in the package-info.java file
  • PackageDeclaration — Ensures there is a package declaration and (optionally) in the correct directory
  • PackageName — Checks that package names conform to a format specified by the format property
  • ParameterAssignment — Disallow assignment of parameters
  • ParameterName — Checks that parameter names conform to a format specified by the format property
  • ParameterNumber — Checks the number of parameters that a method or constructor has
  • ParenPad — Checks the padding of parentheses
  • RedundantImport — Checks for imports that are redundant
  • RedundantModifier — Checks for redundant modifiers in interface and annotation definitions
  • RequireThis — Checks that code doesn’t rely on the
  • ReturnCount — Restricts return statements to a specified count (default = 2)
  • RightCurly — Checks the placement of right curly braces
  • SeparatorWrap — Checks line wrapping with separators
  • SingleLineJavadoc — Checks that a JavaDoc block which can fit on a single line and doesn’t contain at-clauses
  • StaticVariableName — Checks that static, non-final variable names conform to a format specified by the format property
  • SummaryJavadoc — Checks that Javadoc summary sentence does not contain phrases that are not recommended to use
  • SuppressWarnings — This check allows you to specify what warnings that
  • SuppressWarningsHolder — This check allows for finding code that should not be reported by Checkstyle
  • ThrowsCount — Restricts throws statements to a specified count (default = 4)
  • TodoComment — A check for TODO comments
  • TrailingComment — The check to ensure that requires that comments be the only thing on a line
  • Translation — The TranslationCheck class helps to ensure the correct translation of code by checking property files for consistency regarding their keys
  • TypeName — Checks that type names conform to a format specified by the format property
  • TypecastParenPad — Checks the padding of parentheses for typecasts
  • UncommentedMain — Detects uncommented main methods
  • UniqueProperties — Detects duplicated keys in properties files
  • UnnecessaryParentheses — Checks if unnecessary parentheses are used in a statement or expression
  • UpperEll — Checks that long constants are defined with an upper ell
  • VariableDeclarationUsageDistance — Checks the distance between declaration of variable and its first usage
  • VisibilityModifier — Checks visibility of class members
  • WhitespaceAfter — Checks that a token is followed by whitespace
  • WhitespaceAround — Checks that a token is surrounded by whitespace
  • WriteTag — Outputs a JavaDoc tag as information

Apply them now on Codacy.


Edit: We just published an ebook: “The Ultimate Guide to Code Review” based on a survey of 680+ developers. Enjoy!


About Codacy

Codacy is used by thousands of developers to analyze billions of lines of code every day!

Getting started is easy – and free! Just use your  GitHub, Bitbucket or Google account to sign up.

GET STARTED

RELATED
BLOG POSTS

A Guide to Popular Java Static Analysis Tools
Java's popularity as a programming language stems from its platform independence, thanks to the "write once, run anywhere" capability with the Java...
Why coding standards matter
While it might not seem like it from the outside, coding can be a very personal practice. Yes, some coding standards need to be followed in order to...
Codacy Pioneers: A Fellowship Program for Open-Source Creators
Here at Codacy, we recognize the importance of the open-source software (OSS) community and are dedicated to nurturing and supporting it in any way we...

Automate code
reviews on your commits and pull request

Group 13