Method configureSessionCells
has a Cognitive Complexity of 7 (exceeds 5 allowed). Consider refactoring. Open
public void configureSessionCells(Session session) {
if (protocolGraph == null) {
log.info("protocolgraph is null in Protocolgraph!!");
} else {
for (Entry<String, Set<String>> entry : protocolGraph.entrySet()) {
- Read upRead up
- Create a ticketCreate a ticket
Cognitive Complexity
Cognitive Complexity is a measure of how difficult a unit of code is to intuitively understand. Unlike Cyclomatic Complexity, which determines how difficult your code will be to test, Cognitive Complexity tells you how difficult your code will be to read and comprehend.
A method's cognitive complexity is based on a few simple rules:
- Code is not considered more complex when it uses shorthand that the language provides for collapsing multiple statements into one
- Code is considered more complex for each "break in the linear flow of the code"
- Code is considered more complex when "flow breaking structures are nested"
Further reading
Rename field "protocolGraph" Open
private Map<String, Set<String>> protocolGraph = new HashMap<String, Set<String>>();
- Read upRead up
- Create a ticketCreate a ticket
- Exclude checks
It's confusing to have a class member with the same name (case differences aside) as its enclosing class. This is particularly so when you consider the common practice of naming a class instance for the class itself.
Best practice dictates that any field or member with the same name as the enclosing class be renamed to be more descriptive of the particular aspect of the class it represents or holds.
Noncompliant Code Example
public class Foo { private String foo; public String getFoo() { } } Foo foo = new Foo(); foo.getFoo() // what does this return?
Compliant Solution
public class Foo { private String name; public String getName() { } } //... Foo foo = new Foo(); foo.getName()
Exceptions
When the type of the field is the containing class and that field is static, no issue is raised to allow singletons named like the type.
public class Foo { ... private static Foo foo; public Foo getInstance() { if(foo==null) { foo = new Foo(); } return foo; } ... }
Remove this unused method parameter "endLine". Open
ArrayList<String> graphLines, int startLine, int endLine) {
- 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
Extra separation in import group before 'org.springframework.beans.factory.annotation.Autowired' Open
import org.springframework.beans.factory.annotation.Autowired;
- Read upRead up
- Create a ticketCreate a ticket
- 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.
Wrong lexicographical order for 'in.ac.bits.protocolanalyzer.analyzer.CustomAnalyzer' import. Should be before 'org.springframework.stereotype.Component'. Open
import in.ac.bits.protocolanalyzer.analyzer.CustomAnalyzer;
- Read upRead up
- Create a ticketCreate a ticket
- 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.
Wrong lexicographical order for 'in.ac.bits.protocolanalyzer.analyzer.Session' import. Should be before 'org.springframework.stereotype.Component'. Open
import in.ac.bits.protocolanalyzer.analyzer.Session;
- Read upRead up
- Create a ticketCreate a ticket
- 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.
Extra separation in import group before 'in.ac.bits.protocolanalyzer.analyzer.CustomAnalyzer' Open
import in.ac.bits.protocolanalyzer.analyzer.CustomAnalyzer;
- Read upRead up
- Create a ticketCreate a ticket
- 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.
Wrong lexicographical order for 'lombok.Getter' import. Should be before 'org.springframework.stereotype.Component'. Open
import lombok.Getter;
- Read upRead up
- Create a ticketCreate a ticket
- 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.
Wrong lexicographical order for 'lombok.extern.log4j.Log4j' import. Should be before 'org.springframework.stereotype.Component'. Open
import lombok.extern.log4j.Log4j;
- Read upRead up
- Create a ticketCreate a ticket
- 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.
When doing a String.toLowerCase()/toUpperCase() call, use a Locale Open
nodeName = tokens[1].toUpperCase();
- Read upRead up
- Create a ticketCreate a ticket
- Exclude checks
UseLocaleWithCaseConversions
Since: PMD 2.0
Priority: Medium
Categories: Style
Remediation Points: 50000
When doing String.toLowerCase()/toUpperCase() conversions, use Locales to avoids problems with languages that have unusual conventions, i.e. Turkish.
Example:
class Foo {
// BAD
if (x.toLowerCase().equals('list')) { }
/*
* This will not match 'LIST' when in Turkish locale
* The above could be
* if (x.toLowerCase(Locale.US).equals('list')) { }
* or simply
* if (x.equalsIgnoreCase('list')) { }
*/
// GOOD
String z = a.toLowerCase(Locale.EN);
}
When doing a String.toLowerCase()/toUpperCase() call, use a Locale Open
toNodes.add(protocolName.toUpperCase());
- Read upRead up
- Create a ticketCreate a ticket
- Exclude checks
UseLocaleWithCaseConversions
Since: PMD 2.0
Priority: Medium
Categories: Style
Remediation Points: 50000
When doing String.toLowerCase()/toUpperCase() conversions, use Locales to avoids problems with languages that have unusual conventions, i.e. Turkish.
Example:
class Foo {
// BAD
if (x.toLowerCase().equals('list')) { }
/*
* This will not match 'LIST' when in Turkish locale
* The above could be
* if (x.toLowerCase(Locale.US).equals('list')) { }
* or simply
* if (x.equalsIgnoreCase('list')) { }
*/
// GOOD
String z = a.toLowerCase(Locale.EN);
}
When doing a String.toLowerCase()/toUpperCase() call, use a Locale Open
protocolGraph.put(nodeName.toUpperCase(), toNodes);
- Read upRead up
- Create a ticketCreate a ticket
- Exclude checks
UseLocaleWithCaseConversions
Since: PMD 2.0
Priority: Medium
Categories: Style
Remediation Points: 50000
When doing String.toLowerCase()/toUpperCase() conversions, use Locales to avoids problems with languages that have unusual conventions, i.e. Turkish.
Example:
class Foo {
// BAD
if (x.toLowerCase().equals('list')) { }
/*
* This will not match 'LIST' when in Turkish locale
* The above could be
* if (x.toLowerCase(Locale.US).equals('list')) { }
* or simply
* if (x.equalsIgnoreCase('list')) { }
*/
// GOOD
String z = a.toLowerCase(Locale.EN);
}