Skip to content

Checkstyle Miscellaneous

Rules

Checks whether file contains code. [Mandatory]

Files which are considered to have no code:

  • File with no text
  • File with single-line comment(s)
  • File with a multi line comment(s).

❌ 

// single-line comment // violation

/* // violation
block comment
*/

💡 check NoCodeInFile for the original rule.

Checks that the outer type name and the file name match. [Mandatory]

For example, the class Foo must be in a file named Foo.java.

  • Example of class Test in a file named Test.java

✔ 

public class Test { // OK

}

  • Example of class Foo in a file named Test.java

❌ 

class Foo { // violation

}

  • Example of interface Foo in a file named Test.java

❌ 

interface Foo { // violation

}

💡 check OuterTypeFilename for the original rule.

Checks for TODO: comments. [Reference]

Actually it is a generic pattern matcher on Java comments.

💡 Specify (TODO)|(todo) pattern to match comments against.

i++; // TODO: do differently in future   // OK
i++; // todo: do differently in future   // violation

💡 Using TODO: comments is a great way to keep track of tasks that need to be done. Having them reported by Checkstyle makes it very hard to forget about them. And check TodoComment for the original rule.

A main method is often used for debugging purposes. When debugging is finished, developers often forget to remove the method, which changes the API and increases the size of the resulting class or JAR file. Except for the real program entry points, all main methods should be removed or commented out of the sources.

💡 The Spring Boot / Spring Cloud applications of class name with pattern .*Application.* are allowed to have a main method.

✔ 

public class Launch {
    //public static void main(String[] args){} // OK
}

public class Start {
    public void main(){}                       // OK
}

public record MyRecord2 {
   //public void main(){}                     // OK
}

public class Application {
   public static void main(String[] args){}   // OK since class name matches pattern ".*Application.*"

}

❌ 

public class Game {
   public static void main(String... args){}   // violation
}

public class Main {
   public static void main(String[] args){}   // violation
}

public record MyRecord1 {
   public void main(){}                       // violation
}

💡 check UncommentedMain for the original rule.

Detects duplicated keys in properties files. [Mandatory]

Multiple property keys usually appear after merge or rebase of several branches. While there are no problems in runtime, there can be a confusion due to having different values for the duplicated properties.

If want to detect if having any duplicate key for some configuration files, we can define which file type we want to check out.

💡 Such as properties,cfg,yaml,yml file type extension of the files to check.

  • Example: We want to check in foo.properties file
key.one=44
key.two=32   // OK
key.one=54   // violation
key.three=10
key.three=30  // violation

💡 check UniqueProperties for the original rule.

That is 'L' and not 'l'. This is in accordance with the Java Language Specification, Section 3.10.1.

class Test {
   long var1 = 508987; // OK
   long var2 = 508987l; // violation
   long var3 = 508987L; // OK
}

💡 check UpperEll for the original rule.

Reference

Checkstyle - miscellaneous
Weekly meeting minutes 2023-01-12