Refactor this method to reduce its Cognitive Complexity from 21 to the 15 allowed. Open
public synchronized void request(long n) {
- 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 21 to the 15 allowed. Open
public synchronized void request(long n) {
- 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
Rename "future" which hides the field declared at line 1082. Open
ListenableFuture<T> future = this.future;
- Read upRead up
- Create a ticketCreate a ticket
- Exclude checks
Overriding or shadowing a variable declared in an outer scope can strongly impact the readability, and therefore the maintainability, of a piece of code. Further, it could lead maintainers to introduce bugs because they think they're using one variable but are really using another.
Noncompliant Code Example
class Foo { public int myField; public void doSomething() { int myField = 0; ... } }
See
- CERT, DCL01-C. - Do not reuse variable names in subscopes
- CERT, DCL51-J. - Do not shadow or obscure identifiers in subscopes
Either re-interrupt this method or rethrow the "InterruptedException" that can be caught here. Open
} catch (Exception exc) {
- Read upRead up
- Create a ticketCreate a ticket
- Exclude checks
InterruptedExceptions
should never be ignored in the code, and simply logging the exception counts in this case as "ignoring". The
throwing of the InterruptedException
clears the interrupted state of the Thread, so if the exception is not handled properly the fact
that the thread was interrupted will be lost. Instead, InterruptedExceptions
should either be rethrown - immediately or after cleaning up
the method's state - or the thread should be re-interrupted by calling Thread.interrupt()
even if this is supposed to be a
single-threaded application. Any other course of action risks delaying thread shutdown and loses the information that the thread was interrupted -
probably without finishing its task.
Similarly, the ThreadDeath
exception should also be propagated. According to its JavaDoc:
If
ThreadDeath
is caught by a method, it is important that it be rethrown so that the thread actually dies.
Noncompliant Code Example
public void run () { try { while (true) { // do stuff } }catch (InterruptedException e) { // Noncompliant; logging is not enough LOGGER.log(Level.WARN, "Interrupted!", e); } }
Compliant Solution
public void run () { try { while (true) { // do stuff } }catch (InterruptedException e) { LOGGER.log(Level.WARN, "Interrupted!", e); // Restore interrupted state... Thread.currentThread().interrupt(); } }
See
- MITRE, CWE-391 - Unchecked Error Condition
- Dealing with InterruptedException
Rename "future" which hides the field declared at line 963. Open
CompletableFuture<T> future = this.future;
- Read upRead up
- Create a ticketCreate a ticket
- Exclude checks
Overriding or shadowing a variable declared in an outer scope can strongly impact the readability, and therefore the maintainability, of a piece of code. Further, it could lead maintainers to introduce bugs because they think they're using one variable but are really using another.
Noncompliant Code Example
class Foo { public int myField; public void doSomething() { int myField = 0; ... } }
See
- CERT, DCL01-C. - Do not reuse variable names in subscopes
- CERT, DCL51-J. - Do not shadow or obscure identifiers in subscopes
Rename "cancelled" which hides the field declared at line 519. Open
boolean cancelled = false;
- Read upRead up
- Create a ticketCreate a ticket
- Exclude checks
Overriding or shadowing a variable declared in an outer scope can strongly impact the readability, and therefore the maintainability, of a piece of code. Further, it could lead maintainers to introduce bugs because they think they're using one variable but are really using another.
Noncompliant Code Example
class Foo { public int myField; public void doSomething() { int myField = 0; ... } }
See
- CERT, DCL01-C. - Do not reuse variable names in subscopes
- CERT, DCL51-J. - Do not shadow or obscure identifiers in subscopes
Empty line should be followed by <p> tag on the next line.</p> Open
*
- Read upRead up
- Create a ticketCreate a ticket
- Exclude checks
Checks the Javadoc paragraph.
Checks that:
- There is one blank line between each of two paragraphs.
- Each paragraph but the first has <p> immediately before the first word, withno space after.
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 120 characters (found 126). Open
@Override public CompletionStage<Void> runAfterEitherAsync(CompletionStage<?> other, Runnable action, Executor executor) {
- Read upRead up
- Create a ticketCreate a ticket
- 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.
'static' modifier out of order with the JLS suggestions. Open
public final static class ListenableFuturePublisher<T> implements Publisher<T> {
- Read upRead up
- Create a ticketCreate a ticket
- Exclude checks
Checks that the order of modifiers conforms to the suggestions inthe JavaLanguage specification, § 8.1.1, 8.3.1, 8.4.3 and9.4. The correct order is:
public
protected
private
abstract
default
static
final
transient
volatile
synchronized
native
strictfp
In additional, modifiers are checked to ensure all annotations aredeclared before all other modifiers.
Rationale: Code is easier to read if everybody follows a standard.
ATTENTION: We skiptype annotations from validation.
This documentation is written and maintained by the Checkstyle community and is covered under the same license as the Checkstyle project.
'static' modifier out of order with the JLS suggestions. Open
public final static class PublisherListenableFuture<T> implements ListenableFuture<T>, Publisher<T> {
- Read upRead up
- Create a ticketCreate a ticket
- Exclude checks
Checks that the order of modifiers conforms to the suggestions inthe JavaLanguage specification, § 8.1.1, 8.3.1, 8.4.3 and9.4. The correct order is:
public
protected
private
abstract
default
static
final
transient
volatile
synchronized
native
strictfp
In additional, modifiers are checked to ensure all annotations aredeclared before all other modifiers.
Rationale: Code is easier to read if everybody follows a standard.
ATTENTION: We skiptype annotations from validation.
This documentation is written and maintained by the Checkstyle community and is covered under the same license as the Checkstyle project.
'static' modifier out of order with the JLS suggestions. Open
public final static class CompletableFuturePublisher<T>
- Read upRead up
- Create a ticketCreate a ticket
- Exclude checks
Checks that the order of modifiers conforms to the suggestions inthe JavaLanguage specification, § 8.1.1, 8.3.1, 8.4.3 and9.4. The correct order is:
public
protected
private
abstract
default
static
final
transient
volatile
synchronized
native
strictfp
In additional, modifiers are checked to ensure all annotations aredeclared before all other modifiers.
Rationale: Code is easier to read if everybody follows a standard.
ATTENTION: We skiptype annotations from validation.
This documentation is written and maintained by the Checkstyle community and is covered under the same license as the Checkstyle project.