0

I've been looking for the ideal coding patterns used to score well in a Cyclomatic Complexity.

Of course, code will be subject to change according to what is being developed but regardless the objective of the application there will always be the fundamentals: conditions, returns etc.

For an instance, what is considered less complex from the following two examples:

//Example A    

const isDogBarking = false;

if (isDogBarking) {
    return 'Yes, Dog is barking';
}

return 'No, Dog is not barking';

Vs

//Example B

const isDogBarking = false;

return isDogBarking ? 'Yes, Dog is barking' : 'No, Dog is not barking';

In my opinion Example A has two returns and example B has only one. Hence, the latter would be better.

I strive to improve the quality of my code but unfortunately I cannot find the most effective coding pattern in Javascript

EDIT - The following questions has been included in this question.

What does it take to add complexity in code?

  1. Having a function existing (by returning or breaking) at the earliest possible or to return only once at the end?

  2. In an if condition, to check the true value first and add the negative code in the else block? does it make a difference whether to check positivity first rather than the negativity ?

  3. To have a nested if conditions (looking like an arrow) or to create an if condition for each possible outcome instead?

  4. Switch statement does give a better reading than a never-ending if condition. But does it make the code less complex?

These are simple questions which I was hoping to find when it comes to learning about Cyclomatic Complexity.

  • The best way to write quality code is to not make yourself a slave to metrics. – Cort Ammon Aug 11 '17 at 18:42
  • 2
    You're assuming lower cyclomatic complexity is automatically better; it isn't. – whatsisname Aug 11 '17 at 19:32
  • @whatsisname can you elaborate on your comment please? – Matthew Barbara Aug 11 '17 at 19:33
5

I don't think cyclomatic complexity is affected by exit points. It is related to the number of code paths, which will correlate to the number of decision points. One way to look at it is "how many unit tests would I need to write to obtain 100% code coverage?" In your example, you would need two tests, in both cases.

As for design patterns that reduce complexity-- there is no magic pattern that will accomplish this-- but here are two that are well-reputed to make code simpler:

Revealing Module Pattern. Reduces the number of dependencies by keeping as many variables and functions in a private scope as possible.

Guard pattern, a.k.a. "Don't use the arrow anti-pattern!" Reduces the depth of nested ifs and results in a more linear code execution pattern.

Also, if you really want to make huge strides in getting rid of Javascript complexity (especially cross-browser compatibility), consider using jquery on top of Javascript. I can't possibly overstate how huge of a gain it is to use jquery (and how much more fun it is). Once you make the move to jquery, you can also write jquery plugins which will automatically organize your code.

3

From the viewpoint of cyclomatic complexity, the two should (I believe) come out the same. You've changed the syntax, but it doesn't really affect the flow of control.

If you really wanted to change the cyclomatic complexity, you could probably do something like this:

replies = ["No, Dog is not barking", "Yes, Dog is barking"]

return replies[Number(isDogBarking)]

I don't write JS much, so I have have some of that syntax a tiny bit wrong, but I'm reasonably certain the basic idea shows through: convert the boolean value to a number, and use that to index into an array.

3

Short answer: both examples have the same cyclomatic complexity but many tools will calculate the first one to have higher complexity.

Longer answer: "The cyclomatic complexity of a section of source code is the number of linearly independent paths within it." Both examples have the same number of paths therefore they have the same complexity. Many tools add one to the complexity for every return but this is not really correct.

Which one of these you prefer is basically a preference. I prefer the ternary because, once you understand the syntax, it's very easy to grok as long as it's short.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.