I'm creating an enum with reusable pieces of code and the indentation is giving me trouble. We have Checkstyle configured to run as a git commit hook (as well as in out IDE). Here is an example code block for what I am trying to do:
package org.kapunga.weather;
/**
* @author kapunga
*/
public enum FloatMapper {
IDENTITY("identity", o -> o.floatValue()),
CEL_TO_FAREN("celToFaren", t -> {
float f = t.floatValue();
float i = f * (float) 1.8;
return i + 32;
}),
FAREN_TO_CEL("farenToCel", t -> {
float f = t.floatValue();
float i = f - 32;
return i / (float) 1.8;
});
public final String name;
public final FloatMappingFunction func;
FloatMapper(String name, FloatMappingFunction func) {
this.name = name;
this.func = func;
}
@FunctionalInterface
public interface FloatMappingFunction {
float map(Number n);
}
}
When I try and commit this, I get checkstyle warnings:
thor@ma-lt-thor ~/work/r9/trunk (client)$ git commit project/org/kapunga/weather/FloatMapper.java
Java changes found, running Checkstyle.
Checking source files for tabs.
project/org/kapunga/weather/FloatMapper.java:9: warning: 'member def type' have incorrect indentation level 8, expected level should be 4.
project/org/kapunga/weather/FloatMapper.java:10: warning: 'member def type' have incorrect indentation level 8, expected level should be 4.
project/org/kapunga/weather/FloatMapper.java:15: warning: 'member def type' have incorrect indentation level 8, expected level should be 4.
project/org/kapunga/weather/FloatMapper.java:16: warning: 'member def type' have incorrect indentation level 8, expected level should be 4.
Commit aborted.
When I fix this to the following (Which I would argue is less readable):
package org.kapunga.weather;
/**
* @author kapunga
*/
public enum FloatMapper {
IDENTITY("identity", o -> o.floatValue()),
CEL_TO_FAREN("celToFaren", t -> {
float f = t.floatValue();
float i = f * (float) 1.8;
return i + 32;
}),
FAREN_TO_CEL("farenToCel", t -> {
float f = t.floatValue();
float i = f - 32;
return i / (float) 1.8;
});
public final String name;
public final FloatMappingFunction func;
FloatMapper(String name, FloatMappingFunction func) {
this.name = name;
this.func = func;
}
@FunctionalInterface
public interface FloatMappingFunction {
float map(Number n);
}
}
I get errors as well:
thor@ma-lt-thor ~/work/r9/trunk (client)$ git commit project/org/kapunga/weather/FloatMapper.java
Java changes found, running Checkstyle.
Checking source files for tabs.
project/org/kapunga/weather/FloatMapper.java:9: warning: 'block' child have incorrect indentation level 4, expected level should be 8.
project/org/kapunga/weather/FloatMapper.java:10: warning: 'block' child have incorrect indentation level 4, expected level should be 8.
project/org/kapunga/weather/FloatMapper.java:12: warning: 'block' child have incorrect indentation level 4, expected level should be 8.
project/org/kapunga/weather/FloatMapper.java:15: warning: 'block' child have incorrect indentation level 4, expected level should be 8.
project/org/kapunga/weather/FloatMapper.java:16: warning: 'block' child have incorrect indentation level 4, expected level should be 8.
project/org/kapunga/weather/FloatMapper.java:18: warning: 'block' child have incorrect indentation level 4, expected level should be 8.
Commit aborted.
So as you can see, I can't get this to agree on a correct indentation level. I think the first example should be correct, the second example makes it hard to see where each enum begins. When I do something like this:
FloatMappingFunction celToFaren = t -> {
float f = t.floatValue();
float i = f * (float) 1.8;
return i + 32;
};
I have no checkstyle errors.
I'm creating an enum with reusable pieces of code and the indentation is giving me trouble. We have Checkstyle configured to run as a git commit hook (as well as in out IDE). Here is an example code block for what I am trying to do:
When I try and commit this, I get checkstyle warnings:
When I fix this to the following (Which I would argue is less readable):
I get errors as well:
So as you can see, I can't get this to agree on a correct indentation level. I think the first example should be correct, the second example makes it hard to see where each enum begins. When I do something like this:
I have no checkstyle errors.