When i ran PMD on my Java Code , one of the Error Message it is showing is
"The class STWeb has a Cyclomatic Complexity , of 20 " .
Typically my java class is of this way
public class STWeb implements STWebService {
public String getData(RequestData request)
{
validate(request);
}
public boolean validate(Data[] formdata)
{
if(formdata.length==1)
//do this
else if(formdata.length==3)
//do this
else if(formdata.length==4)
//do this
else if(formdata.length>4)
//do this
else if(formdata.length==2)
{
if(formdata[0].getName.equals("OIY"))
{
}
/ And many more if else here
}
}
}
As you can see , as per my business requirements , i need to code the class
with many if's and if else so the reason the cyclocomplexity has ncreased , please tell me
what is feasible approach as per the standard for this ??
Cyclomatic Complexity measurements shouldn't be used for quality control, but rather as an indicator/warning for bad code. You should focus more on the code behind it rather than the value of the CC itself.
Although you can reduce the complexity of the validate method by splitting it into smaller methods through refactoring, the class as a whole will still have the same CC.
As long as the code is readable and makes sense to the next person that has to look at it, then having a higher CC shouldn't matter so much.
It helps if you have something like this:
if (a) {
return true;
} else if (b) {
return true;
} else if (c) {
return true;
} else {
return false;
}
then, you replace it with this:
return a || b || c;
Just wanted to add, that sometimes it's possible to resolve such problems with object- or structure-building. You could declare a "Wrapper-Class" for your data that is supposed to be returned. But there are always cases when you can't apply this without bloating the code with tons of objects, which in return also results in unreadable code ^^"
EDIT: this SO-post is a [nice example with ENUMS]
Cyclomatic complexity seems to indicate the amount of code paths that exist. So if your requirements say you must use many ifs and if elses, then you can ignore that message.
If this is mandatory - yes this happens despite it's futil - you can often reduce the class cyclomatic complexity by introducing base classes and move distribute the functions into the base classes until the per class cyclomatic complexity is ok.
Or simpler: add // NOPMD to your class:
public class VeryComplexStuff { // NOPMD
...
Related
I am using lot of if statements to check.Like:
if(statement 1){
block 1;
}
if(statement 2){
block 2;
}
...//about at least 20 if
if(statement n){
block n;
}
To avoid using too many if-statement, I have tried to use strategy pattern which would create validator class for each if-statement.Like:
public interface Validator<SomeObejct>{
public Result validate(SomeObject o);
}
public class SomeValidator implements Validator<SomeObject> {
#Override
public boolean validate(SomeObject o) throw Exception{
if(statement 1){
block 1;
}
}
Because I may have at least 20 if-statement, it may need at least 20 validator classes. So if there is any better solution for that? Or how can I manage these 20 validotor classes?
Edit:
To be more specific, I am writing some code for checking the problem on my schedule. For example:
if(currentDate > mustFinishDate){
warning();
}
if(NotScheduleADateForThisTask){
warning();
}
if(DateFormatNotCorrect){
error();
}
Above the date check may also be the if-statement block.
You can use the Composite pattern to maintain a list of all validators:
class ValidatorComposite<T> implements Validator<T> {
List<Validator<T>> validators = new ArrayList<>();
public void addValidator(Validator<T> add) { validators.add(add)); }
public Result validate(T toValidate) {
Result result = Result.OK;
for (Validator<T> v : validators) {
result = v.validate(toValidate);
if (result != Result.OK) break;
}
return result;
}
}
and since Validator only has one method, for Java 8 it's a functional interface, so you don't really need "20 classes" but can create a list on the fly using lambdas.
ValidatorComposite<SomeObject> val = new ValidatorComposite<>();
val.addValidator(so -> condition1 ? block1(so) : Result.OK);
val.addValidator(so -> condition2 ? block2(so) : Result.OK);
and so on.
Your code sample isn't really consistent because first you declare Validator to return Result and later let the implementation return boolean (and even throws an Exception), so I kind of intergrated both by ignoring the exception and using a Result.OK value.
these days what you should not probably care about is performance because of power of computers. now most programmers try to write readable and clean codes.
so i believe if writing 20 ifs makes your code easier to understand and more flexible its not bad to implement that.
BTW you can use switch case too.
switch (variable){
case 1:{
//block 1
}
case 2:{
//block2
}
...
}
if your cases are not similar and have different aspects using that Validator pattern will lead to inflexibility(It may lead to this point, it depends on situation).
Our team's Java Coding Guideline says:
Avoid using "!" in if statement as much as possible.
I have asked other colleagues, but no one gave me clear ideas why, because the guideline was created a long time ago and the author might have left our company.
Do you have any idea?
With the information provided, this calls for some speculation. One possible reason is that the intent was not for an if-statement by itself but for an if-else statement. In that case, I can see where you might say that you should reverse the cases so that you don't have the extra operation of the negation. Instead of
if (! boolVar) {
// Something
} else {
// Something else
}
you might prefer
if (boolVar) {
// Something else
} else {
// Something
}
Whether this is worth it or not is probably more a matter of taste and standardization than anything else.
The rule is likely an adaptation from Robert Martin's Clean Code, page 302:
Negatives are just a bit harder to understand than positives. So, when possible, conditionals should be expressed as positives. For example:
if(buffer.shouldCompact())
is preferable to
if(!buffer.shouldNotCompact())
As an example, suppose you're creating a validator that requires two things to be false for the entity to be valid:
The entity must not have been created within the last 12 hours, and
The entity's bank account total sum must not exceed $50,000.
Naturally the idea would be to write two methods for this:
boolean isCreatedWithinLastTwelveHours(BankAccount account)
boolean hasMoreThanTotalSumCap(BankAccount account)
...at which point, you then invoke these as:
boolean newAccount = isCreatedWithinTheLastTwelveHours(account);
boolean highEndAccount = hasMoreThanTotalSumCap(account);
if(!newAccount && !highEndAccount) { // ... other logic
// The more astute would use DeMorgan's law in an effort to make this more readable
if(!(newAccount || highEndAccount)) { // other logic
Well...wouldn't it be nicer if you just said what they weren't instead?
boolean isNotCreatedWithinLastTwelveHours(BankAccount account)
boolean hasLessThanTotalSumCap(BankAccount account)
That'd make the expression a bit more concise:
if(notNewAccount && notHighEndAccount) { // .. carry on!
Of course "!" can be used when you like. There is no "unless" in java and you have no other choices in some conditions.
Looks like yet-another-useless-rule. Generally speaking, there are no absolute terms in this scenario, true that if you are in a if-else clause then possibly it is better to write
if(myCondition) {
doThis()
} else {
doSomethingElse()
}
Instead of
if(!myCondition) {
doSomethingElse()
} else {
doThis()
}
However, that said, in some scenarios is actually quite ok to use the negation operator, particularly if no else clause is provided, example
if (!tokenDoesCompute()) {
throw InvalidTockenException("Whatever")
}
And actually in that scenario, using "!" makes quite a bit of sense for me.
Finally, if no one can really explain WHY the rule is there, maybe it is time to remove it, the only good reason I could find for it would be to provide consistency regarding the code style.
Okay, I answer my own question.
As other say, maybe this is written for the readability.
In The Art of Readable Code (p. 72) says:
Prefer dealing with the positive case first instead of the negative-e.g., if(debug) instead of if(!debug)
I found below post as well:
Readable Code - Remove Checking null
bool func(String name)
{
if ( (name != null) && (name.equals("true") ) {
//...
} else {
//...
}
}
bool func(String name)
{
if ( "true".equals(name) ) {
//...
} else {
//...
}
}
Ofcourse you can use the negation operator ! whenever you like.
However, if you have a situation where you have to write some actions in both if and else block then the following is more readable :
if(status){
//do something
}
else{
//do something else
}
than
if(!status){
//do something
}
else{
//do something else
}
But if you have situation where you only need to perform certain actions based on just one condition, i.e. if you have only an if block & no else block, then it is reasonably fine to use ! in if
I haven't seen anyone else suggest this, which is probably because they hate it as much as I do, but I'm showing it for completeness.
// Using not operator (preferred)
if (! someTest) { ... }
// Using compact not operator (kind of hides it)
if (!someTest) { ... }
// Comparing to false (ok, explicitly states what you want)
if (someTest == false) { ... }
// Comparing to true (a bit obscure)
if (someTest != true) { ... }
They all do the same, but please keep using !, just make sure you add a space after it, so it's easier to see.
For the following piece of code, sonarqube computes the method cyclomatic complexity as 9
String foo() {
if (cond1) return a;
if (cond2) return b;
if (cond3) return c;
if (cond4) return d;
return e;
}
I understand as per the rules for computation http://docs.sonarqube.org/display/SONAR/Metrics+-+Complexity the complexity of 9 is correct.
So complexity of the method is = 4 (if) + 4 (return) + 1 (method) = 9
This complexity can be reduced, if I have a single exit point.
String foo() {
String temp;
if (cond1) {
temp = a;
} else if (cond2) {
temp = b;
} else if (cond3) {
temp = c;
} else if (cond4) {
temp = d;
} else {
temp = e;
}
return temp;
}
I believe this code is more cluttered and unreadable than the previous version and I feel having methods with return on guard conditions is a better programming practice. So is there a good reason why return statement is considered for computation of cyclomatic complexity? Can the logic for computation be changed so that it doesn't promote single exit point.
I agree you should use some common sense and go with the code which you believe is simplest.
BTW You can simplify you code and have just one return if you use ? :
String foo() {
return cond1 ? a :
cond2 ? b :
cond3 ? c :
cond4 ? d : e;
}
"So is there a good reason why return statement is considered for
computation of cyclomatic complexity? Can the logic for computation be
changed so that it doesn't promote single exit point."
In your example having multiple returns doesn't add to the complexity and as #Peter Lawrey says you should employ common sense.
Does this mean that all examples of multiple return statements do not to complexity and it should be removed? I don't think so. If would be very easy to come up with an example of a method which is hard-to-read because of multiple return statements. Just imagine a 100 line method with 4 different return statement sprinkled throughout. That is the kind of issue this rules tries to catch.
This is a known problem with cyclomatic complexity.
Also there is good reason to think that cyclomatic complexity is useless. It correlates strongly with SLOC and only weakly with actual bugs. In fact SLOC is just as good a predictor of defects as cyclomatic complexity. The same goes for most other complexity metrics.
See http://www.leshatton.org/Documents/TAIC2008-29-08-2008.pdf, starting around slide 16.
Other answers have made good points about the computation involved.
I'd like to point out that your assertion that the code is less readable is false, because in one instance you have braces, and in the other you don't.
String foo() {
String output = e;
if (cond1) output = a;
else if (cond2) output = b;
else if (cond3) output = c;
else if (cond4) output = d;
return output;
}
This is as readable as the example you gave with return statements.
Whether or not you allow braceless if statements is a question of style that you should probably be consistent with across all your code.
The more important issue that cyclomatic complexity does address is that if computing the value of cond1, cond2 etc have side effects, i.e. if they were a stateful method rather than a field in this case, then the conceptual complexity of the code is much higher if you might return early compared to if you can't.
This is a simplified example. I have this enum declaration as follows:
public enum ELogLevel {
None,
Debug,
Info,
Error
}
I have this code in another class:
if ((CLog._logLevel == ELogLevel.Info) || (CLog._logLevel == ELogLevel.Debug) || (CLog._logLevel == ELogLevel.Error)) {
System.out.println(formatMessage(message));
}
My question is if there is a way to shorten the test. Ideally i would like somethign to the tune of (this is borrowed from Pascal/Delphi):
if (CLog._logLevel in [ELogLevel.Info, ELogLevel.Debug, ELogLevel.Error])
Instead of the long list of comparisons. Is there such a thing in Java, or maybe a way to achieve it? I am using a trivial example, my intention is to find out if there is a pattern so I can do these types of tests with enum value lists of many more elements.
EDIT: It looks like EnumSet is the closest thing to what I want. The Naïve way of implementing it is via something like:
if (EnumSet.of(ELogLevel.Info, ELogLevel.Debug, ELogLevel.Error).contains(CLog._logLevel))
But under benchmarking, this performs two orders of magnitude slower than the long if/then statement, I guess because the EnumSet is being instantiated every time it runs. This is a problem only for code that runs very often, and even then it's a very minor problem, since over 100M iterations we are talking about 7ms vs 450ms on my box; a very minimal amount of time either way.
What I settled on for code that runs very often is to pre-instantiate the EnumSet in a static variable, and use that instance in the loop, which cuts down the runtime back down to a much more palatable 9ms over 100M iterations.
So it looks like we have a winner! Thanks guys for your quick replies.
what you want is an enum set
http://docs.oracle.com/javase/1.5.0/docs/api/java/util/EnumSet.html
put the elements you want to test for in the set, and then use the Set method contains().
import java.util.EnumSet;
public class EnumSetExample
{
enum Level { NONE, DEBUG, INFO, ERROR };
public static void main(String[] args)
{
EnumSet<Level> subset = EnumSet.of(Level.DEBUG, Level.INFO);
for(Level currentLevel : EnumSet.allOf(Level.class))
{
if (subset.contains(currentLevel))
{
System.out.println("we have " + currentLevel.toString());
}
else
{
System.out.println("we don't have " + currentLevel.toString());
}
}
}
}
There's no way to do it concisely in Java. The closest you can come is to dump the values in a set and call contains(). An EnumSet is probably most efficient in your case. You can shorted the set initialization a little using the double brace idiom, though this has the drawback of creating a new inner class each time you use it, and hence increases the memory usage slightly.
In general, logging levels are implemented as integers:
public static int LEVEL_NONE = 0;
public static int LEVEL_DEBUG = 1;
public static int LEVEL_INFO = 2;
public static int LEVEL_ERROR = 3;
and then you can test for severity using simple comparisons:
if (Clog._loglevel >= LEVEL_DEBUG) {
// log
}
You could use a list of required levels, ie:
List<ELogLevel> levels = Lists.newArrayList(ELogLevel.Info,
ELogLevel.Debug, ELogLevel.Error);
if (levels.contains(CLog._logLevel)) {
//
}
We have App A as main app. Now we build from it App B which uses a subset of App A's functionality.
App A stays like it is whereas app B only uses a subset of A
So I want to refactor the function without or with as little dublication as possible and with maximum readability.
So the function looks like this (it is actually longer, this is an excerpt):
class SomeClass {
Data prepareData() {
if (this.bothId==1 || this.appAid=2 /*or only relevant for appA*/) {
if(this.data==null) { /*appA*/
appAdoSmth(); /*appA*/
}
boolean merge=false; /*appA*/
if (this.data==null) { /*appA*/
merge=appAanalyze(data); /*appA*/
}
bothPrepare(merge);
} else if (bothIsRelevant()) {
if(appArelevant()) { /*appA*/
data=appAprepare(); /*appA*/
} else {
data=prepareBoth();
}
bothUpdateSomeValue();
}
}
How would you do it?
Other Answers address the general question of how to refactor code. They offer good advice, but I don't think it is what you are asking.
I think you are asking about possible refactorings of the code in your question.
It is hard to give an answer that is generally applicable, or even specifically applicable. (The sample code isn't your real code, and it is a little difficult to understand what it actually "means").
AndreasD gives one approach: break the big complicated nested if into separate methods.
Another approach is to use the Stragegy design pattern. Separate the code that is specific to each app into strategy classes. For example:
interface Strategy {
Data prepareData();
}
class GeneralStrategy implements Strategy {
Data prepareData() {
// do general preparation
}
}
class App1Strategy extends GeneralStrategy {
Data prepareData() {
// do app1-specific preparation
super.prepareData();
// do more app1-specific preparation
}
}
and so on.
I ideal world develop unit test that validates that existing implementation of your function works.
Then start changing code incrementally and run your test after every change.
It is hard to give your formal recommendation without knowing your code structure. But generally try to find duplicate code fragments, write methods that implement this logic with parameters and replace the duplicate fragments to your new method. Etc, etc.
Good luck.
Readbility can be improved by extracting some logic in separate methods. That is a refactoring method.
Data prepareData() {
if (this.bothId==1 || this.appAid=2 ) {
handleCase1(); // <- you'll find better names for the methods
} else if (bothIsRelevant()) {
handleCase2();
}
}
private void handleCase1() {
if(this.data==null) {
appAdoSmth();
}
boolean merge=false;
if (this.data==null) {
merge=appAanalyze(data);
}
bothPrepare(merge);
}
private handleCase2() {
if(appArelevant()) {
data=appAprepare();
} else {
data=prepareBoth();
}
bothUpdateSomeValue();
}
This doesn't reduce the number of if/else, of course, but it keeps the "main" method simple.
If I were you I would run a coverage report on this class. (e.g. http://ecobertura.johoop.de/ or http://www.eclemma.org/) This way Eclipse can show covered lines green and this helps you to identify the cases. With this aid it's much easier to separate green lines and pull them into methods.