Showing 213 of 213 total issues
TODO found Open
// Only applied if the Hunter has a specific perk //TODO Perks for insta kill
- Create a ticketCreate a ticket
- Exclude checks
Add a default case to this switch. Open
switch (dplayer.getPlayerState().getEndGameState()) {
- Read upRead up
- Create a ticketCreate a ticket
- Exclude checks
The requirement for a final default
clause is defensive programming. The clause should either take appropriate action, or contain a
suitable comment as to why no action is taken.
Noncompliant Code Example
switch (param) { //missing default clause case 0: doSomething(); break; case 1: doSomethingElse(); break; } switch (param) { default: // default clause should be the last one error(); break; case 0: doSomething(); break; case 1: doSomethingElse(); break; }
Compliant Solution
switch (param) { case 0: doSomething(); break; case 1: doSomethingElse(); break; default: error(); break; }
Exceptions
If the switch
parameter is an Enum
and if all the constants of this enum are used in the case
statements,
then no default
clause is expected.
Example:
public enum Day { SUNDAY, MONDAY } ... switch(day) { case SUNDAY: doSomething(); break; case MONDAY: doSomethingElse(); break; }
See
- MITRE, CWE-478 - Missing Default Case in Switch Statement
- CERT, MSC01-C. - Strive for logical completeness
Refactor this method to reduce its Cognitive Complexity from 22 to the 15 allowed. Open
public void editorBlockBreakEntity(PlayerInteractAtEntityEvent e) {
- Read upRead up
- Create a ticketCreate a ticket
- Exclude checks
Cognitive Complexity is a measure of how hard the control flow of a method is to understand. Methods with high Cognitive Complexity will be difficult to maintain.
See
Refactor this method to reduce its Cognitive Complexity from 18 to the 15 allowed. Open
public boolean addToMatchmaking(Player p, String playType) {
- Read upRead up
- Create a ticketCreate a ticket
- Exclude checks
Cognitive Complexity is a measure of how hard the control flow of a method is to understand. Methods with high Cognitive Complexity will be difficult to maintain.
See
Use try-with-resources or close this "Statement" in a "finally" clause. Open
Statement statement = connection.createStatement();
- Read upRead up
- Create a ticketCreate a ticket
- Exclude checks
Connections, streams, files, and other classes that implement the Closeable
interface or its super-interface,
AutoCloseable
, needs to be closed after use. Further, that close
call must be made in a finally
block otherwise
an exception could keep the call from being made. Preferably, when class implements AutoCloseable
, resource should be created using
"try-with-resources" pattern and will be closed automatically.
Failure to properly close resources will result in a resource leak which could bring first the application and then perhaps the box the application is on to their knees.
Noncompliant Code Example
private void readTheFile() throws IOException { Path path = Paths.get(this.fileName); BufferedReader reader = Files.newBufferedReader(path, this.charset); // ... reader.close(); // Noncompliant // ... Files.lines("input.txt").forEach(System.out::println); // Noncompliant: The stream needs to be closed } private void doSomething() { OutputStream stream = null; try { for (String property : propertyList) { stream = new FileOutputStream("myfile.txt"); // Noncompliant // ... } } catch (Exception e) { // ... } finally { stream.close(); // Multiple streams were opened. Only the last is closed. } }
Compliant Solution
private void readTheFile(String fileName) throws IOException { Path path = Paths.get(fileName); try (BufferedReader reader = Files.newBufferedReader(path, StandardCharsets.UTF_8)) { reader.readLine(); // ... } // .. try (Stream<String> input = Files.lines("input.txt")) { input.forEach(System.out::println); } } private void doSomething() { OutputStream stream = null; try { stream = new FileOutputStream("myfile.txt"); for (String property : propertyList) { // ... } } catch (Exception e) { // ... } finally { stream.close(); } }
Exceptions
Instances of the following classes are ignored by this rule because close
has no effect:
-
java.io.ByteArrayOutputStream
-
java.io.ByteArrayInputStream
-
java.io.CharArrayReader
-
java.io.CharArrayWriter
-
java.io.StringReader
-
java.io.StringWriter
Java 7 introduced the try-with-resources statement, which implicitly closes Closeables
. All resources opened in a try-with-resources
statement are ignored by this rule.
try (BufferedReader br = new BufferedReader(new FileReader(fileName))) { //... } catch ( ... ) { //... }
See
- MITRE, CWE-459 - Incomplete Cleanup
- MITRE, CWE-772 - Missing Release of Resource after Effective Lifetime
- CERT, FIO04-J. - Release resources when they are no longer needed
- CERT, FIO42-C. - Close files when they are no longer needed
- Try With Resources
Merge this if statement with the enclosing one. Open
if (e.getLine(1).equalsIgnoreCase("join")) {
- Read upRead up
- Create a ticketCreate a ticket
- Exclude checks
Merging collapsible if
statements increases the code's readability.
Noncompliant Code Example
if (file != null) { if (file.isFile() || file.isDirectory()) { /* ... */ } }
Compliant Solution
if (file != null && isFileOrDirectory(file)) { /* ... */ } private static boolean isFileOrDirectory(File file) { return file.isFile() || file.isDirectory(); }
Use try-with-resources or close this "Statement" in a "finally" clause. Open
Statement statement = connection.createStatement();
- Read upRead up
- Create a ticketCreate a ticket
- Exclude checks
Connections, streams, files, and other classes that implement the Closeable
interface or its super-interface,
AutoCloseable
, needs to be closed after use. Further, that close
call must be made in a finally
block otherwise
an exception could keep the call from being made. Preferably, when class implements AutoCloseable
, resource should be created using
"try-with-resources" pattern and will be closed automatically.
Failure to properly close resources will result in a resource leak which could bring first the application and then perhaps the box the application is on to their knees.
Noncompliant Code Example
private void readTheFile() throws IOException { Path path = Paths.get(this.fileName); BufferedReader reader = Files.newBufferedReader(path, this.charset); // ... reader.close(); // Noncompliant // ... Files.lines("input.txt").forEach(System.out::println); // Noncompliant: The stream needs to be closed } private void doSomething() { OutputStream stream = null; try { for (String property : propertyList) { stream = new FileOutputStream("myfile.txt"); // Noncompliant // ... } } catch (Exception e) { // ... } finally { stream.close(); // Multiple streams were opened. Only the last is closed. } }
Compliant Solution
private void readTheFile(String fileName) throws IOException { Path path = Paths.get(fileName); try (BufferedReader reader = Files.newBufferedReader(path, StandardCharsets.UTF_8)) { reader.readLine(); // ... } // .. try (Stream<String> input = Files.lines("input.txt")) { input.forEach(System.out::println); } } private void doSomething() { OutputStream stream = null; try { stream = new FileOutputStream("myfile.txt"); for (String property : propertyList) { // ... } } catch (Exception e) { // ... } finally { stream.close(); } }
Exceptions
Instances of the following classes are ignored by this rule because close
has no effect:
-
java.io.ByteArrayOutputStream
-
java.io.ByteArrayInputStream
-
java.io.CharArrayReader
-
java.io.CharArrayWriter
-
java.io.StringReader
-
java.io.StringWriter
Java 7 introduced the try-with-resources statement, which implicitly closes Closeables
. All resources opened in a try-with-resources
statement are ignored by this rule.
try (BufferedReader br = new BufferedReader(new FileReader(fileName))) { //... } catch ( ... ) { //... }
See
- MITRE, CWE-459 - Incomplete Cleanup
- MITRE, CWE-772 - Missing Release of Resource after Effective Lifetime
- CERT, FIO04-J. - Release resources when they are no longer needed
- CERT, FIO42-C. - Close files when they are no longer needed
- Try With Resources
Merge this if statement with the enclosing one. Open
if (main.getSignManager().getSign(e.getClickedBlock()).getGame() != null) {
- Read upRead up
- Create a ticketCreate a ticket
- Exclude checks
Merging collapsible if
statements increases the code's readability.
Noncompliant Code Example
if (file != null) { if (file.isFile() || file.isDirectory()) { /* ... */ } }
Compliant Solution
if (file != null && isFileOrDirectory(file)) { /* ... */ } private static boolean isFileOrDirectory(File file) { return file.isFile() || file.isDirectory(); }
Remove this "Class.forName()", it is useless. (sonar.java.source not set. Assuming 6 or greater.) Open
Class.forName("com.mysql.jdbc.Driver");
- Read upRead up
- Create a ticketCreate a ticket
- Exclude checks
In the past, it was required to load a JDBC driver before creating a java.sql.Connection
. Nowadays, when using JDBC 4.0 drivers, this
is no longer required and Class.forName()
can be safely removed because JDBC 4.0 (JDK 6) drivers available in the classpath are
automatically loaded.
This rule raises an issue when Class.forName()
is used with one of the following values:
-
com.mysql.jdbc.Driver
-
oracle.jdbc.driver.OracleDriver
-
com.ibm.db2.jdbc.app.DB2Driver
-
com.ibm.db2.jdbc.net.DB2Driver
-
com.sybase.jdbc.SybDriver
-
com.sybase.jdbc2.jdbc.SybDriver
-
com.teradata.jdbc.TeraDriver
-
com.microsoft.sqlserver.jdbc.SQLServerDriver
-
org.postgresql.Driver
-
sun.jdbc.odbc.JdbcOdbcDriver
-
org.hsqldb.jdbc.JDBCDriver
-
org.h2.Driver
-
org.firebirdsql.jdbc.FBDriver
-
net.sourceforge.jtds.jdbc.Driver
-
com.ibm.db2.jcc.DB2Driver
Noncompliant Code Example
import java.sql.Connection; import java.sql.DriverManager; import java.sql.SQLException; public class Demo { private static final String DRIVER_CLASS_NAME = "org.postgresql.Driver"; private final Connection connection; public Demo(String serverURI) throws SQLException, ClassNotFoundException { Class.forName(DRIVER_CLASS_NAME); // Noncompliant; no longer required to load the JDBC Driver using Class.forName() connection = DriverManager.getConnection(serverURI); } }
Compliant Solution
import java.sql.Connection; import java.sql.DriverManager; import java.sql.SQLException; public class Demo { private final Connection connection; public Demo(String serverURI) throws SQLException { connection = DriverManager.getConnection(serverURI); } }
Refactor this method to reduce its Cognitive Complexity from 25 to the 15 allowed. Open
public void loadArenasFromFile() {
- Read upRead up
- Create a ticketCreate a ticket
- Exclude checks
Cognitive Complexity is a measure of how hard the control flow of a method is to understand. Methods with high Cognitive Complexity will be difficult to maintain.
See
Refactor this method to not always return the same value. Open
public boolean onCommand(CommandSender commandSender, Command command, String s, String[] strings) {
- Read upRead up
- Create a ticketCreate a ticket
- Exclude checks
When a method is designed to return an invariant value, it may be poor design, but it shouldn't adversely affect the outcome of your program. However, when it happens on all paths through the logic, it is surely a bug.
This rule raises an issue when a method contains several return
statements that all return the same value.
Noncompliant Code Example
int foo(int a) { int b = 12; if (a == 1) { return b; } return b; // Noncompliant }
Refactor this method to reduce its Cognitive Complexity from 17 to the 15 allowed. Open
public boolean onCommand(CommandSender commandSender, Command command, String s, String[] args) {
- Read upRead up
- Create a ticketCreate a ticket
- Exclude checks
Cognitive Complexity is a measure of how hard the control flow of a method is to understand. Methods with high Cognitive Complexity will be difficult to maintain.
See
Remove these unused method parameters. Open
public boolean onCommand(CommandSender commandSender, Command command, String s, String[] args) {
- Read upRead up
- Create a ticketCreate a ticket
- Exclude checks
Unused parameters are misleading. Whatever the values passed to such parameters, the behavior will be the same.
Noncompliant Code Example
void doSomething(int a, int b) { // "b" is unused compute(a); }
Compliant Solution
void doSomething(int a) { compute(a); }
Exceptions
The rule will not raise issues for unused parameters:
- that are annotated with
@javax.enterprise.event.Observes
- in overrides and implementation methods
- in interface
default
methods - in non-private methods that only
throw
or that have empty bodies - in annotated methods, unless the annotation is
@SuppressWarning("unchecked")
or@SuppressWarning("rawtypes")
, in which case the annotation will be ignored - in overridable methods (non-final, or not member of a final class, non-static, non-private), if the parameter is documented with a proper javadoc.
@Override void doSomething(int a, int b) { // no issue reported on b compute(a); } public void foo(String s) { // designed to be extended but noop in standard case } protected void bar(String s) { //open-closed principle } public void qix(String s) { throw new UnsupportedOperationException("This method should be implemented in subclasses"); } /** * @param s This string may be use for further computation in overriding classes */ protected void foobar(int a, String s) { // no issue, method is overridable and unused parameter has proper javadoc compute(a); }
See
- CERT, MSC12-C. - Detect and remove code that has no effect or is never executed