Method saveToNodeSettings
has a Cognitive Complexity of 15 (exceeds 5 allowed). Consider refactoring. Open
@Override
public void saveToNodeSettings(NodeSettingsWO settings) {
SettingsHelper.addInt(CONDID, condId, settings);
SettingsHelper.addString(COMBASEID, combaseId, settings);
agent.saveToNodeSettings(settings.addNodeSettings(AGENT));
- 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
Method loadFromNodeSettings
has a Cognitive Complexity of 15 (exceeds 5 allowed). Consider refactoring. Open
@Override
public void loadFromNodeSettings(NodeSettingsRO settings) throws InvalidSettingsException {
condId = SettingsHelper.getInteger(CONDID, settings);
combaseId = SettingsHelper.getString(COMBASEID, settings);
agent.loadFromNodeSettings(settings.getNodeSettings(AGENT));
- 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 "dbuuid" to prevent any misunderstanding/clash with field "DBUUID" defined on line 22. Open
public String dbuuid;
- Read upRead up
- Create a ticketCreate a ticket
- Exclude checks
Looking at the set of methods in a class, including superclass methods, and finding two methods or fields that differ only by capitalization is confusing to users of the class. It is similarly confusing to have a method and a field which differ only in capitalization or a method and a field with exactly the same name and visibility.
In the case of methods, it may have been a mistake on the part of the original developer, who intended to override a superclass method, but instead added a new method with nearly the same name.
Otherwise, this situation simply indicates poor naming. Method names should be action-oriented, and thus contain a verb, which is unlikely in the case where both a method and a member have the same name (with or without capitalization differences). However, renaming a public method could be disruptive to callers. Therefore renaming the member is the recommended action.
Noncompliant Code Example
public class Car{ public DriveTrain drive; public void tearDown(){...} public void drive() {...} // Noncompliant; duplicates field name } public class MyCar extends Car{ public void teardown(){...} // Noncompliant; not an override. It it really what's intended? public void drivefast(){...} public void driveFast(){...} //Huh? }
Compliant Solution
public class Car{ private DriveTrain drive; public void tearDown(){...} public void drive() {...} // field visibility reduced } public class MyCar extends Car{ @Override public void tearDown(){...} public void drivefast(){...} public void driveReallyFast(){...} }
Rename field "databaseWritable" to prevent any misunderstanding/clash with field "DATABASEWRITABLE" defined on line 32. Open
public Boolean databaseWritable;
- Read upRead up
- Create a ticketCreate a ticket
- Exclude checks
Looking at the set of methods in a class, including superclass methods, and finding two methods or fields that differ only by capitalization is confusing to users of the class. It is similarly confusing to have a method and a field which differ only in capitalization or a method and a field with exactly the same name and visibility.
In the case of methods, it may have been a mistake on the part of the original developer, who intended to override a superclass method, but instead added a new method with nearly the same name.
Otherwise, this situation simply indicates poor naming. Method names should be action-oriented, and thus contain a verb, which is unlikely in the case where both a method and a member have the same name (with or without capitalization differences). However, renaming a public method could be disruptive to callers. Therefore renaming the member is the recommended action.
Noncompliant Code Example
public class Car{ public DriveTrain drive; public void tearDown(){...} public void drive() {...} // Noncompliant; duplicates field name } public class MyCar extends Car{ public void teardown(){...} // Noncompliant; not an override. It it really what's intended? public void drivefast(){...} public void driveFast(){...} //Huh? }
Compliant Solution
public class Car{ private DriveTrain drive; public void tearDown(){...} public void drive() {...} // field visibility reduced } public class MyCar extends Car{ @Override public void tearDown(){...} public void drivefast(){...} public void driveReallyFast(){...} }
Rename field "emLit" to prevent any misunderstanding/clash with field "EMLIT" defined on line 31. Open
public LiteratureList emLit = new LiteratureList();
- Read upRead up
- Create a ticketCreate a ticket
- Exclude checks
Looking at the set of methods in a class, including superclass methods, and finding two methods or fields that differ only by capitalization is confusing to users of the class. It is similarly confusing to have a method and a field which differ only in capitalization or a method and a field with exactly the same name and visibility.
In the case of methods, it may have been a mistake on the part of the original developer, who intended to override a superclass method, but instead added a new method with nearly the same name.
Otherwise, this situation simply indicates poor naming. Method names should be action-oriented, and thus contain a verb, which is unlikely in the case where both a method and a member have the same name (with or without capitalization differences). However, renaming a public method could be disruptive to callers. Therefore renaming the member is the recommended action.
Noncompliant Code Example
public class Car{ public DriveTrain drive; public void tearDown(){...} public void drive() {...} // Noncompliant; duplicates field name } public class MyCar extends Car{ public void teardown(){...} // Noncompliant; not an override. It it really what's intended? public void drivefast(){...} public void driveFast(){...} //Huh? }
Compliant Solution
public class Car{ private DriveTrain drive; public void tearDown(){...} public void drive() {...} // field visibility reduced } public class MyCar extends Car{ @Override public void tearDown(){...} public void drivefast(){...} public void driveReallyFast(){...} }
Rename field "mdInfo" to prevent any misunderstanding/clash with field "MDINFO" defined on line 20. Open
public MdInfo mdInfo = new MdInfo();
- Read upRead up
- Create a ticketCreate a ticket
- Exclude checks
Looking at the set of methods in a class, including superclass methods, and finding two methods or fields that differ only by capitalization is confusing to users of the class. It is similarly confusing to have a method and a field which differ only in capitalization or a method and a field with exactly the same name and visibility.
In the case of methods, it may have been a mistake on the part of the original developer, who intended to override a superclass method, but instead added a new method with nearly the same name.
Otherwise, this situation simply indicates poor naming. Method names should be action-oriented, and thus contain a verb, which is unlikely in the case where both a method and a member have the same name (with or without capitalization differences). However, renaming a public method could be disruptive to callers. Therefore renaming the member is the recommended action.
Noncompliant Code Example
public class Car{ public DriveTrain drive; public void tearDown(){...} public void drive() {...} // Noncompliant; duplicates field name } public class MyCar extends Car{ public void teardown(){...} // Noncompliant; not an override. It it really what's intended? public void drivefast(){...} public void driveFast(){...} //Huh? }
Compliant Solution
public class Car{ private DriveTrain drive; public void tearDown(){...} public void drive() {...} // field visibility reduced } public class MyCar extends Car{ @Override public void tearDown(){...} public void drivefast(){...} public void driveReallyFast(){...} }
Rename field "matrix" to prevent any misunderstanding/clash with field "MATRIX" defined on line 18. Open
public Matrix matrix = new Matrix();
- Read upRead up
- Create a ticketCreate a ticket
- Exclude checks
Looking at the set of methods in a class, including superclass methods, and finding two methods or fields that differ only by capitalization is confusing to users of the class. It is similarly confusing to have a method and a field which differ only in capitalization or a method and a field with exactly the same name and visibility.
In the case of methods, it may have been a mistake on the part of the original developer, who intended to override a superclass method, but instead added a new method with nearly the same name.
Otherwise, this situation simply indicates poor naming. Method names should be action-oriented, and thus contain a verb, which is unlikely in the case where both a method and a member have the same name (with or without capitalization differences). However, renaming a public method could be disruptive to callers. Therefore renaming the member is the recommended action.
Noncompliant Code Example
public class Car{ public DriveTrain drive; public void tearDown(){...} public void drive() {...} // Noncompliant; duplicates field name } public class MyCar extends Car{ public void teardown(){...} // Noncompliant; not an override. It it really what's intended? public void drivefast(){...} public void driveFast(){...} //Huh? }
Compliant Solution
public class Car{ private DriveTrain drive; public void tearDown(){...} public void drive() {...} // field visibility reduced } public class MyCar extends Car{ @Override public void tearDown(){...} public void drivefast(){...} public void driveReallyFast(){...} }
Rename field "condId" to prevent any misunderstanding/clash with field "CONDID" defined on line 14. Open
public Integer condId;
- Read upRead up
- Create a ticketCreate a ticket
- Exclude checks
Looking at the set of methods in a class, including superclass methods, and finding two methods or fields that differ only by capitalization is confusing to users of the class. It is similarly confusing to have a method and a field which differ only in capitalization or a method and a field with exactly the same name and visibility.
In the case of methods, it may have been a mistake on the part of the original developer, who intended to override a superclass method, but instead added a new method with nearly the same name.
Otherwise, this situation simply indicates poor naming. Method names should be action-oriented, and thus contain a verb, which is unlikely in the case where both a method and a member have the same name (with or without capitalization differences). However, renaming a public method could be disruptive to callers. Therefore renaming the member is the recommended action.
Noncompliant Code Example
public class Car{ public DriveTrain drive; public void tearDown(){...} public void drive() {...} // Noncompliant; duplicates field name } public class MyCar extends Car{ public void teardown(){...} // Noncompliant; not an override. It it really what's intended? public void drivefast(){...} public void driveFast(){...} //Huh? }
Compliant Solution
public class Car{ private DriveTrain drive; public void tearDown(){...} public void drive() {...} // field visibility reduced } public class MyCar extends Car{ @Override public void tearDown(){...} public void drivefast(){...} public void driveReallyFast(){...} }
Rename field "agent" to prevent any misunderstanding/clash with field "AGENT" defined on line 17. Open
public Agent agent = new Agent();
- Read upRead up
- Create a ticketCreate a ticket
- Exclude checks
Looking at the set of methods in a class, including superclass methods, and finding two methods or fields that differ only by capitalization is confusing to users of the class. It is similarly confusing to have a method and a field which differ only in capitalization or a method and a field with exactly the same name and visibility.
In the case of methods, it may have been a mistake on the part of the original developer, who intended to override a superclass method, but instead added a new method with nearly the same name.
Otherwise, this situation simply indicates poor naming. Method names should be action-oriented, and thus contain a verb, which is unlikely in the case where both a method and a member have the same name (with or without capitalization differences). However, renaming a public method could be disruptive to callers. Therefore renaming the member is the recommended action.
Noncompliant Code Example
public class Car{ public DriveTrain drive; public void tearDown(){...} public void drive() {...} // Noncompliant; duplicates field name } public class MyCar extends Car{ public void teardown(){...} // Noncompliant; not an override. It it really what's intended? public void drivefast(){...} public void driveFast(){...} //Huh? }
Compliant Solution
public class Car{ private DriveTrain drive; public void tearDown(){...} public void drive() {...} // field visibility reduced } public class MyCar extends Car{ @Override public void tearDown(){...} public void drivefast(){...} public void driveReallyFast(){...} }
Rename field "litMd" to prevent any misunderstanding/clash with field "LITMD" defined on line 21. Open
public LiteratureList litMd = new LiteratureList();
- Read upRead up
- Create a ticketCreate a ticket
- Exclude checks
Looking at the set of methods in a class, including superclass methods, and finding two methods or fields that differ only by capitalization is confusing to users of the class. It is similarly confusing to have a method and a field which differ only in capitalization or a method and a field with exactly the same name and visibility.
In the case of methods, it may have been a mistake on the part of the original developer, who intended to override a superclass method, but instead added a new method with nearly the same name.
Otherwise, this situation simply indicates poor naming. Method names should be action-oriented, and thus contain a verb, which is unlikely in the case where both a method and a member have the same name (with or without capitalization differences). However, renaming a public method could be disruptive to callers. Therefore renaming the member is the recommended action.
Noncompliant Code Example
public class Car{ public DriveTrain drive; public void tearDown(){...} public void drive() {...} // Noncompliant; duplicates field name } public class MyCar extends Car{ public void teardown(){...} // Noncompliant; not an override. It it really what's intended? public void drivefast(){...} public void driveFast(){...} //Huh? }
Compliant Solution
public class Car{ private DriveTrain drive; public void tearDown(){...} public void drive() {...} // field visibility reduced } public class MyCar extends Car{ @Override public void tearDown(){...} public void drivefast(){...} public void driveReallyFast(){...} }
Rename field "combaseId" to prevent any misunderstanding/clash with field "COMBASEID" defined on line 15. Open
public String combaseId;
- Read upRead up
- Create a ticketCreate a ticket
- Exclude checks
Looking at the set of methods in a class, including superclass methods, and finding two methods or fields that differ only by capitalization is confusing to users of the class. It is similarly confusing to have a method and a field which differ only in capitalization or a method and a field with exactly the same name and visibility.
In the case of methods, it may have been a mistake on the part of the original developer, who intended to override a superclass method, but instead added a new method with nearly the same name.
Otherwise, this situation simply indicates poor naming. Method names should be action-oriented, and thus contain a verb, which is unlikely in the case where both a method and a member have the same name (with or without capitalization differences). However, renaming a public method could be disruptive to callers. Therefore renaming the member is the recommended action.
Noncompliant Code Example
public class Car{ public DriveTrain drive; public void tearDown(){...} public void drive() {...} // Noncompliant; duplicates field name } public class MyCar extends Car{ public void teardown(){...} // Noncompliant; not an override. It it really what's intended? public void drivefast(){...} public void driveFast(){...} //Huh? }
Compliant Solution
public class Car{ private DriveTrain drive; public void tearDown(){...} public void drive() {...} // field visibility reduced } public class MyCar extends Car{ @Override public void tearDown(){...} public void drivefast(){...} public void driveReallyFast(){...} }
Rename field "estModel" to prevent any misunderstanding/clash with field "ESTMODEL" defined on line 25. Open
public EstModel estModel = new EstModel();
- Read upRead up
- Create a ticketCreate a ticket
- Exclude checks
Looking at the set of methods in a class, including superclass methods, and finding two methods or fields that differ only by capitalization is confusing to users of the class. It is similarly confusing to have a method and a field which differ only in capitalization or a method and a field with exactly the same name and visibility.
In the case of methods, it may have been a mistake on the part of the original developer, who intended to override a superclass method, but instead added a new method with nearly the same name.
Otherwise, this situation simply indicates poor naming. Method names should be action-oriented, and thus contain a verb, which is unlikely in the case where both a method and a member have the same name (with or without capitalization differences). However, renaming a public method could be disruptive to callers. Therefore renaming the member is the recommended action.
Noncompliant Code Example
public class Car{ public DriveTrain drive; public void tearDown(){...} public void drive() {...} // Noncompliant; duplicates field name } public class MyCar extends Car{ public void teardown(){...} // Noncompliant; not an override. It it really what's intended? public void drivefast(){...} public void driveFast(){...} //Huh? }
Compliant Solution
public class Car{ private DriveTrain drive; public void tearDown(){...} public void drive() {...} // field visibility reduced } public class MyCar extends Car{ @Override public void tearDown(){...} public void drivefast(){...} public void driveReallyFast(){...} }
Rename field "mLit" to prevent any misunderstanding/clash with field "MLIT" defined on line 30. Open
public LiteratureList mLit = new LiteratureList();
- Read upRead up
- Create a ticketCreate a ticket
- Exclude checks
Looking at the set of methods in a class, including superclass methods, and finding two methods or fields that differ only by capitalization is confusing to users of the class. It is similarly confusing to have a method and a field which differ only in capitalization or a method and a field with exactly the same name and visibility.
In the case of methods, it may have been a mistake on the part of the original developer, who intended to override a superclass method, but instead added a new method with nearly the same name.
Otherwise, this situation simply indicates poor naming. Method names should be action-oriented, and thus contain a verb, which is unlikely in the case where both a method and a member have the same name (with or without capitalization differences). However, renaming a public method could be disruptive to callers. Therefore renaming the member is the recommended action.
Noncompliant Code Example
public class Car{ public DriveTrain drive; public void tearDown(){...} public void drive() {...} // Noncompliant; duplicates field name } public class MyCar extends Car{ public void teardown(){...} // Noncompliant; not an override. It it really what's intended? public void drivefast(){...} public void driveFast(){...} //Huh? }
Compliant Solution
public class Car{ private DriveTrain drive; public void tearDown(){...} public void drive() {...} // field visibility reduced } public class MyCar extends Car{ @Override public void tearDown(){...} public void drivefast(){...} public void driveReallyFast(){...} }