Showing 50 of 51 total issues
Line is longer than 100 characters (found 109). Open
* Returns the closest holder to location which already contains at least one item of the given material.
- Read upRead up
- Exclude checks
Checks for long lines.
Rationale: Long lines are hard to read in printouts or if developershave limited screen space for the source code, e.g. if the IDEdisplays additional information like project tree, class hierarchy,etc.
This documentation is written and maintained by the Checkstyle community and is covered under the same license as the Checkstyle project.
Line is longer than 100 characters (found 127). Open
Location targetLoc = new Location(chestLocation.getWorld(), 0, 0, 0).add(chestLocation).add(deltaX, 0, deltaZ);
- Read upRead up
- Exclude checks
Checks for long lines.
Rationale: Long lines are hard to read in printouts or if developershave limited screen space for the source code, e.g. if the IDEdisplays additional information like project tree, class hierarchy,etc.
This documentation is written and maintained by the Checkstyle community and is covered under the same license as the Checkstyle project.
Line is longer than 100 characters (found 130). Open
* @return The number of items that could not be removed, if amount was higher than the total number of items in the inventory
- Read upRead up
- Exclude checks
Checks for long lines.
Rationale: Long lines are hard to read in printouts or if developershave limited screen space for the source code, e.g. if the IDEdisplays additional information like project tree, class hierarchy,etc.
This documentation is written and maintained by the Checkstyle community and is covered under the same license as the Checkstyle project.
Wrong lexicographical order for 'java.util.Map' import. Should be before 'org.bukkit.Material'. Open
import java.util.Map;
- Read upRead up
- Exclude checks
Checks that the groups of import declarations appear in the order specifiedby the user. If there is an import but its group is not specified in theconfiguration such an import should be placed at the end of the import list.
This documentation is written and maintained by the Checkstyle community and is covered under the same license as the Checkstyle project.
Line is longer than 100 characters (found 127). Open
Map<Material, CacheEntry<Location>> materialMap = this.holder.computeIfAbsent(organizerLocation, k -> new HashMap<>());
- Read upRead up
- Exclude checks
Checks for long lines.
Rationale: Long lines are hard to read in printouts or if developershave limited screen space for the source code, e.g. if the IDEdisplays additional information like project tree, class hierarchy,etc.
This documentation is written and maintained by the Checkstyle community and is covered under the same license as the Checkstyle project.
'&&' should be on a new line. Open
!(clickedHolder instanceof Player && (action == InventoryAction.MOVE_TO_OTHER_INVENTORY)) && // We are moving (shift-clicking) items, so interesting ones are on slot
- Read upRead up
- Exclude checks
Checks the policy on how to wrap lines on operators.
This documentation is written and maintained by the Checkstyle community and is covered under the same license as the Checkstyle project.
Wrong lexicographical order for 'java.util.Set' import. Should be before 'org.bukkit.plugin.java.JavaPlugin'. Open
import java.util.Set;
- Read upRead up
- Exclude checks
Checks that the groups of import declarations appear in the order specifiedby the user. If there is an import but its group is not specified in theconfiguration such an import should be placed at the end of the import list.
This documentation is written and maintained by the Checkstyle community and is covered under the same license as the Checkstyle project.
Line is longer than 100 characters (found 125). Open
log.info("Moved " + (toRemove.getAmount()) + " " + items.getType() + " to " + targetChest.getLocation());
- Read upRead up
- Exclude checks
Checks for long lines.
Rationale: Long lines are hard to read in printouts or if developershave limited screen space for the source code, e.g. if the IDEdisplays additional information like project tree, class hierarchy,etc.
This documentation is written and maintained by the Checkstyle community and is covered under the same license as the Checkstyle project.
Add a private constructor to hide the implicit public one. Open
public class Util {
- Read upRead up
- Exclude checks
Utility classes, which are collections of static
members, are not meant to be instantiated. Even abstract utility classes, which can
be extended, should not have public constructors.
Java adds an implicit public constructor to every class which does not define at least one explicitly. Hence, at least one non-public constructor should be defined.
Noncompliant Code Example
class StringUtils { // Noncompliant public static String concatenate(String s1, String s2) { return s1 + s2; } }
Compliant Solution
class StringUtils { // Compliant private StringUtils() { throw new IllegalStateException("Utility class"); } public static String concatenate(String s1, String s2) { return s1 + s2; } }
Exceptions
When class contains public static void main(String[] args)
method it is not considered as utility class and will be ignored by this
rule.
Remove this unused "RANGE_VERTICAL" private field. Open
private static final int RANGE_VERTICAL = 1;
- Read upRead up
- Exclude checks
If a private
field is declared but not used in the program, it can be considered dead code and should therefore be removed. This will
improve maintainability because developers will not wonder what the variable is used for.
Note that this rule does not take reflection into account, which means that issues will be raised on private
fields that are only
accessed using the reflection API.
Noncompliant Code Example
public class MyClass { private int foo = 42; public int compute(int a) { return a * 42; } }
Compliant Solution
public class MyClass { public int compute(int a) { return a * 42; } }
Exceptions
The Java serialization runtime associates with each serializable class a version number, called serialVersionUID
, which is used during
deserialization to verify that the sender and receiver of a serialized object have loaded classes for that object that are compatible with respect to
serialization.
A serializable class can declare its own serialVersionUID
explicitly by declaring a field named serialVersionUID
that
must be static, final, and of type long. By definition those serialVersionUID
fields should not be reported by this rule:
public class MyClass implements java.io.Serializable { private static final long serialVersionUID = 42L; }
Moreover, this rule doesn't raise any issue on annotated fields.