Refactor this method to reduce its Cognitive Complexity from 16 to the 15 allowed. Open
private void joinTransactionScenarioStats(int runNumber, LrProjectScenarioResults lrProjectScenarioResults,
- Read upRead up
- 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 19 to the 15 allowed. Open
public synchronized void getUpdatedData() {
- Read upRead up
- 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 static access with "java.util.Map" for "Entry". Open
for (SortedMap.Entry<String, LrProjectScenarioResults> scenarioResults : _projectResult.getScenarioResults()
- Read upRead up
- Exclude checks
In the interest of code clarity, static
members of a base
class should never be accessed using a derived type's name.
Doing so is confusing and could create the illusion that two different static members exist.
Noncompliant Code Example
class Parent { public static int counter; } class Child extends Parent { public Child() { Child.counter++; // Noncompliant } }
Compliant Solution
class Parent { public static int counter; } class Child extends Parent { public Child() { Parent.counter++; } }
Replace this "Map.containsKey()" with a call to "Map.computeIfAbsent()". Open
if (!projectTransactionsData.containsKey(transactionName)) {
- Read upRead up
- Exclude checks
It's a common pattern to test the result of a java.util.Map.get()
against null
or calling
java.util.Map.containsKey()
before proceeding with adding or changing the value in the map. However the java.util.Map
API
offers a significantly better alternative in the form of the computeIfPresent()
and computeIfAbsent()
methods. Using these
instead leads to cleaner and more readable code.
Note that this rule is automatically disabled when the project's sonar.java.source
is not 8.
Noncompliant Code Example
V value = map.get(key); if (value == null) { // Noncompliant value = V.createFor(key); if (value != null) { map.put(key, value); } } if (!map.containsKey(key)) { // Noncompliant value = V.createFor(key); if (value != null) { map.put(key, value); } } return value;
Compliant Solution
return map.computeIfAbsent(key, k -> V.createFor(k));
Exceptions
This rule will not raise an issue when trying to add null
to a map, because computeIfAbsent
will not add the entry if the
value returned by the function is null
.
See also
- {rule:java:S6104} - Map "computeIfAbsent()" and "computeIfPresent()" should not be used to add "null" values.
Use static access with "java.util.Map" for "Entry". Open
for (SortedMap.Entry<String, Integer> vUserStat : scenarioRunResult.vUserSum.entrySet()) {
- Read upRead up
- Exclude checks
In the interest of code clarity, static
members of a base
class should never be accessed using a derived type's name.
Doing so is confusing and could create the illusion that two different static members exist.
Noncompliant Code Example
class Parent { public static int counter; } class Child extends Parent { public Child() { Child.counter++; // Noncompliant } }
Compliant Solution
class Parent { public static int counter; } class Child extends Parent { public Child() { Parent.counter++; } }
This block of commented-out lines of code should be removed. Open
// updateLastBuild();
- Read upRead up
- Exclude checks
Programmers should not comment out code as it bloats programs and reduces readability.
Unused code should be deleted and can be retrieved from source control history if required.
Use static access with "java.util.Map" for "Entry". Open
for (SortedMap.Entry<String, Integer> transactionState : scenarioTransactionSum.entrySet()) {
- Read upRead up
- Exclude checks
In the interest of code clarity, static
members of a base
class should never be accessed using a derived type's name.
Doing so is confusing and could create the illusion that two different static members exist.
Noncompliant Code Example
class Parent { public static int counter; } class Child extends Parent { public Child() { Child.counter++; // Noncompliant } }
Compliant Solution
class Parent { public static int counter; } class Child extends Parent { public Child() { Parent.counter++; } }
This block of commented-out lines of code should be removed. Open
// .size());
- Read upRead up
- Exclude checks
Programmers should not comment out code as it bloats programs and reduces readability.
Unused code should be deleted and can be retrieved from source control history if required.
Remove this unused "LOGGER" private field. Open
private static final Logger LOGGER = Logger
- 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.
This block of commented-out lines of code should be removed. Open
// LrGraphUtils.constructVuserGraph(scenarioResults, scenarioGraphData);
- Read upRead up
- Exclude checks
Programmers should not comment out code as it bloats programs and reduces readability.
Unused code should be deleted and can be retrieved from source control history if required.
Use static access with "java.util.Map" for "Entry". Open
for (SortedMap.Entry<String, TreeMap<String, Integer>> scenarioTransactionDataSet :
- Read upRead up
- Exclude checks
In the interest of code clarity, static
members of a base
class should never be accessed using a derived type's name.
Doing so is confusing and could create the illusion that two different static members exist.
Noncompliant Code Example
class Parent { public static int counter; } class Child extends Parent { public Child() { Child.counter++; // Noncompliant } }
Compliant Solution
class Parent { public static int counter; } class Child extends Parent { public Child() { Parent.counter++; } }
Remove this unused "lastBuildId" private field. Open
private int lastBuildId = -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.
Remove this unused "projectActions" private field. Open
private Collection<Action> projectActions;
- 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.
This block of commented-out lines of code should be removed. Open
// this.buildPerformanceReportList = new ArrayList<String>(0);
- Read upRead up
- Exclude checks
Programmers should not comment out code as it bloats programs and reduces readability.
Unused code should be deleted and can be retrieved from source control history if required.
This block of commented-out lines of code should be removed. Open
// for (AbstractBuild<?, ?> currentBuild : builds) {
- Read upRead up
- Exclude checks
Programmers should not comment out code as it bloats programs and reduces readability.
Unused code should be deleted and can be retrieved from source control history if required.
Remove this unused "jobLrResults" private field. Open
private ArrayList<LrJobResults> jobLrResults;
- 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.
This block of commented-out lines of code should be removed. Open
// List<? extends AbstractBuild<?, ?>> builds = currentProject.getBuilds();
- Read upRead up
- Exclude checks
Programmers should not comment out code as it bloats programs and reduces readability.
Unused code should be deleted and can be retrieved from source control history if required.
Replace this "Map.containsKey()" with a call to "Map.computeIfAbsent()". Open
if (!vUserPerRun.containsKey(runNumber)) {
- Read upRead up
- Exclude checks
It's a common pattern to test the result of a java.util.Map.get()
against null
or calling
java.util.Map.containsKey()
before proceeding with adding or changing the value in the map. However the java.util.Map
API
offers a significantly better alternative in the form of the computeIfPresent()
and computeIfAbsent()
methods. Using these
instead leads to cleaner and more readable code.
Note that this rule is automatically disabled when the project's sonar.java.source
is not 8.
Noncompliant Code Example
V value = map.get(key); if (value == null) { // Noncompliant value = V.createFor(key); if (value != null) { map.put(key, value); } } if (!map.containsKey(key)) { // Noncompliant value = V.createFor(key); if (value != null) { map.put(key, value); } } return value;
Compliant Solution
return map.computeIfAbsent(key, k -> V.createFor(k));
Exceptions
This rule will not raise an issue when trying to add null
to a map, because computeIfAbsent
will not add the entry if the
value returned by the function is null
.
See also
- {rule:java:S6104} - Map "computeIfAbsent()" and "computeIfPresent()" should not be used to add "null" values.
This block of commented-out lines of code should be removed. Open
// if (null == this.currentProject.getSomeBuildWithWorkspace()) {
- Read upRead up
- Exclude checks
Programmers should not comment out code as it bloats programs and reduces readability.
Unused code should be deleted and can be retrieved from source control history if required.
This block of commented-out lines of code should be removed. Open
// public Collection<? extends Action> getProjectActions() {
- Read upRead up
- Exclude checks
Programmers should not comment out code as it bloats programs and reduces readability.
Unused code should be deleted and can be retrieved from source control history if required.
This block of commented-out lines of code should be removed. Open
// getUpdatedData();
- Read upRead up
- Exclude checks
Programmers should not comment out code as it bloats programs and reduces readability.
Unused code should be deleted and can be retrieved from source control history if required.
This block of commented-out lines of code should be removed. Open
// final Run<?, ?> lastBuild = currentProject.getLastBuild();
- Read upRead up
- Exclude checks
Programmers should not comment out code as it bloats programs and reduces readability.
Unused code should be deleted and can be retrieved from source control history if required.
Remove this unused private "updateLastBuild" method. Open
private void updateLastBuild() {
- Read upRead up
- Exclude checks
private
methods that are never executed are dead code: unnecessary, inoperative code that should be removed. Cleaning out dead code
decreases the size of the maintained codebase, making it easier to understand the program and preventing bugs from being introduced.
Note that this rule does not take reflection into account, which means that issues will be raised on private
methods that are only
accessed using the reflection API.
Noncompliant Code Example
public class Foo implements Serializable { private Foo(){} //Compliant, private empty constructor intentionally used to prevent any direct instantiation of a class. public static void doSomething(){ Foo foo = new Foo(); ... } private void unusedPrivateMethod(){...} private void writeObject(ObjectOutputStream s){...} //Compliant, relates to the java serialization mechanism private void readObject(ObjectInputStream in){...} //Compliant, relates to the java serialization mechanism }
Compliant Solution
public class Foo implements Serializable { private Foo(){} //Compliant, private empty constructor intentionally used to prevent any direct instantiation of a class. public static void doSomething(){ Foo foo = new Foo(); ... } private void writeObject(ObjectOutputStream s){...} //Compliant, relates to the java serialization mechanism private void readObject(ObjectInputStream in){...} //Compliant, relates to the java serialization mechanism }
Exceptions
This rule doesn't raise any issue on annotated methods.