Friday, October 10, 2014

Sevntu Checkstyle release 1.12.0

Official page: http://sevntu-checkstyle.github.io/sevntu.checkstyle/#1.12.0

New and noteworthy:




Increased Check's handling of redundant returns in constructors and void methods, particularly: fixed problem of handling redundant returns in try-catch-finally blocks. Done by Aleksey Nesterenko.


Now this Check puts violation on throwing anonymous exception even in case if it is defined before throwing. Done by Aleksey Nesterenko.


Now check prints The Current Line Length In all it's warnings. Done by Aleksey Nesterenko.


This Check highlights variable definition statements where diamond operator could be used.
Rationale: using diamond operator (introduced in Java 1.7) leads to shorter code
and better code readability. It is suggested by Oracle that the diamond primarily using
for variable declarations. E.g. of statements: 

Without diamond operator:

Map<String, Map<String, Integer>> someMap = new HashMap<String, Map<String, Integer>>();

With diamond operator:

Map<String, Map<String, Integer>> someMap = new HashMap<>(); 

Done by Aleksey Nesterenko.



This Check warns on propagation of inner private types to outer classes:
- Externally accessible method if it returns private inner type.
- Externally accessible field if it's type is a private inner type.
These types could be private inner classes, interfaces or enumerations.

Example: 

 class OuterClass {

  public InnerClass innerFromMain = new InnerClass(); //WARNING
  private class InnerClass { ... } 
  public InnerClass  getValue() { //WARNING
      return new InnerClass(); 
  }
   
  private interface InnerInterface { ... }
  public Set<InnerInterface> getValue() { //WARNING
      return new TreeSet<InnerInterface>;
  }
  
  private Enum Fruit {Apple, Pear}
  public Fruit getValue() { //WARNING
      return Fruit.Apple;
  }
  
  public someMethod(InnerClass innerClass) { ... }  //WARNING
  
 }

Rationale: it is possible to return private inner type or use it as the parameter of non-private method, but it is impossible to use it in other classes (besides inner classes) unless it extends or implements at least one non-private class or interface. Such situation usually happens after bulk refactoring and usually means dead/useless code.

Done by Aleksey Nesterenko.
  • Replaced existing NestedTernaryCheck with more general TernaryPerExpressionCountCheck.
New TernaryPerExpressionCountCheck restricts the number of ternary operators in expression to a specific limit.

Rationale: This Check helps to improve code readability by pointing developer on
expressions which contain more than user-defined count of ternary operators.

It points to complicated ternary expressions. Reason:
- Complicated ternary expressions are not easy to read.
- Complicated ternary expressions could lead to ambiguous result if user
does not know Java's operators priority well, e.g.:

 String str = null;
 String x = str != null ? "A" : "B" + str == null ? "C" : "D";
 System.out.println(x);

Output for code above is "D", but more obvious would be "BC".

Check has following properties:
maxTernaryPerExpressionCount - limit of ternary operators per expression
ignoreTernaryOperatorsInBraces - if true Check will ignore ternary operators
in braces (braces explicitly set priority level)
ignoreIsolatedTernaryOnLine - if true Check will ignore one line ternary operators,
if only it is places in line alone.
Options ignoreTernaryOperatorsInBraces and ignoreIsolatedTernaryOnLine can
make Check less strict, e.g.:
Using ignoreTernaryOperatorsInBraces option (value = true)
does not put violation on code below:

 callString = "{? = call " +
   (StringUtils.hasLength(catalogNameToUse) 
   ? catalogNameToUse + "." : "") +
   (StringUtils.hasLength(schemaNameToUse) 
   ? schemaNameToUse + "." : "") +
   procedureNameToUse + "(";

When using ignoreIsolatedTernaryOnLine (value = true), even without
ignoreTernaryOperatorsInBraces option Check won't warn on code below:

 int a = (d == 5) ? d : f
   +
   ((d == 6) ? g : k); 

Done by Aleksey Nesterenko.


  • Update in CustomDeclarationOrderCheck

Updated Check to treat more king of methods as setters. E.g., now Check treats 'set' method as setter, in cases like:

public void setWorkMode(String workMode) {
this.workMode = WorkMode.valueOf(workMode);
}

public void setUserCache(UserCache userCache) {
super.setUserCache(userCache);
}

public void setY(Integer y) { // setter
this.y = Integer.parseInt(y + "");
}

Done by Alexey Nesterenko.

General information:

Repository: https://github.com/sevntu-checkstyle/sevntu.checkstyle
mail-list: https://groups.google.com/forum/?hl=en#!forum/sevntu-checkstyle

No comments:

Post a Comment