AbstractClassWithoutAbstractMethod
This abstract class does not have any abstract methods
The Codiga Code Analysis engine supports hundreds of rules for Java, checking that your code is safe and secure. Start using Codiga today to check your code and automate your code reviews to find issues in every pull request and merge with confidence.
This abstract class does not have any abstract methods
Possible unsafe assignment to a non-final static field in a constructor.
Avoid creating BigDecimal with a decimal (float/double) literal. Use a String literal
Deeply nested if..then statements are hard to read
An instanceof check is being performed on the caught exception. Create a separate catch clause for this exception type.
Avoid protected fields in a final class. Change to private or package access.
Avoid protected methods in a final class that doesnt extend anything other than Object. Change to private or package access.
Use block level rather than method level synchronization
Avoid using java.lang.ThreadGroup; it is not thread safe
Do not hard code the IP address
Do not start a literal by 0 unless its an octal value
Avoid equality comparisons with Double.NaN
Dont create instances of already existing BigInteger and BigDecimal.
Always check the return of one of the navigation method (next
Check the value returned by the skip() method of an InputStream to see if the requested number of bytes has been skipped.
This usage of the Collection.toArray() method will throw a ClassCastException.
Ensure that resources like this PipedWriter object are closed after use
These nested if statements could be combined
Use equals() to compare object references.
Avoid if (x != y) ..; else ..;
Avoid constants in interfaces. Interfaces define types
The default label should be the last label in a switch statement
Dont use floating point for loop indices. If you must use floating point
Fields should be declared at the top of the class
This final field could be made static
This for loop could be simplified to a while loop
Possible God Class
Avoid idempotent operations (like assigning a variable to itself).
Private field could be made final; it is only initialized in the declaration or constructor.
Avoid modifying an outer loop incrementer in an inner loop for update expression
Use opposite operator instead of the logic complement operator.
The null check here is misplaced; if the variable is null there will be a NullPointerException
A switch statement does not contain a break
Class cannot be instantiated and does not provide any static methods or fields
A non-case label was present in a switch statement
Non-static initializers are confusing
Singleton is not thread safe
This call to Collection.toArray() may be optimizable
Ensure you override both equals() and hashCode()
Position literals first in String comparisons for EqualsIgnoreCase
Position literals first in String comparisons
New exception is thrown in catch block
Avoid returning from a finally block
When instantiating a SimpleDateFormat object
Ternary operators that can be simplified with || or &&
Avoid unnecessary comparisons in boolean expressions
Avoid unnecessary if..then..else statements when returning booleans
No need to check for null before an instanceof
A high ratio of statements to labels in a switch statement. Consider refactoring.
Switch statements should have a default label
A switch with less than three branches is inefficient
Document empty constructor
Document empty method body
Do not use if statements that are always true or always false
Consider simply returning the value vs storing it in local variable
Static DateFormatter objects should be accessed in a synchronized manner
Substitute calls and make them more efficient. (e.g. is .useEmpty() instead of .size() == 0)
Use explicit locale when doing a String.toLowerCase()/toUpperCase() call
Call Thread.notifyAll() rather than Thread.notify()
We use cookies to improve your site experience, including analytics cookies to understand how you use our product and design better experiences. Please read our Cookie Policy.