I definitely like the write-up! I love to see software quality metrics being discussed. I do want to point out in your first example:
varmsg="";if(month==12&&day==25){// + 2msg="Merry Christmas";// +1}else{msg="Have a nice day";// +1}returnmsg;// +1 - Total 5
Your suggested reduction in cyclomatic complexity (which I agree with) actually increases your essential complexity... though not above the structured/unstructured threshold. You add an additional exit point to the function, which is a trade off. Your second example:
The essential complexity is 8 because each case is an exit, as well as the default case. In this example, you don't need any trade-offs between cyclomatic and essential complexity; it's bad all the way around. The threshold we use on my quality team (based on McCabe) are that a method in OO code with an essential complexity of greater than 4 is considered to be unstructured.
Again, I'm definitely glad to see good editorials on software quality metrics. Thanks for the post!
"Your suggested reduction in cyclomatic complexity (which I agree with) actually increases your essential complexity... though not above the structured/unstructured threshold. You add an additional exit point to the function, which is a trade off. Your second example:
"
Additional exit point will not be added since the msg variable will have a default, then you only change the content of the variable when the if statement evaluate to true, and only one return statement is needed.
Thanks for the comment. I like the introduction to essential complexity. So long as the same code metrics are used throughout the codebase they should give an insight into code smells and areas ripe for refactoring!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I definitely like the write-up! I love to see software quality metrics being discussed. I do want to point out in your first example:
Your suggested reduction in cyclomatic complexity (which I agree with) actually increases your essential complexity... though not above the structured/unstructured threshold. You add an additional exit point to the function, which is a trade off. Your second example:
The essential complexity is 8 because each case is an exit, as well as the
default
case. In this example, you don't need any trade-offs between cyclomatic and essential complexity; it's bad all the way around. The threshold we use on my quality team (based on McCabe) are that a method in OO code with an essential complexity of greater than 4 is considered to be unstructured.Again, I'm definitely glad to see good editorials on software quality metrics. Thanks for the post!
"Your suggested reduction in cyclomatic complexity (which I agree with) actually increases your essential complexity... though not above the structured/unstructured threshold. You add an additional exit point to the function, which is a trade off. Your second example:
"
Additional exit point will not be added since the msg variable will have a default, then you only change the content of the variable when the if statement evaluate to true, and only one return statement is needed.
You're absolutely right. I was mixing code samples in my head. Thanks for the correction!
Very true! Thanks for the comment.
Thanks for the comment. I like the introduction to essential complexity. So long as the same code metrics are used throughout the codebase they should give an insight into code smells and areas ripe for refactoring!