#cyclomatic complexity

public function escape($subject) { if (is_array($subject)) { $escaped = array(); foreach ($subject as $key => $value) { $values[$key] = $this->escape($value); } return $escaped; } if (is_string($subject)) { return "'" . $this->database->escape($subject) . "'"; } return $subject; }

The method has a cyclomatic complexity of 3, because there are two if conditions and one foreach loop. It's as simple as that.

As you can imagine, a method with more loops and conditions, nested or otherwise, would add to this complexity until it becomes a burden to understand when reading it for the first time.

To make it easier for fellow developers to understand your intent, and to avoid creating potential for things to go wrong (like bugs), it's helpful to minimise this complexity as much as possible. More explicitly, it helps to keep the program in a predictable state.

So how do you go about reducing such complexity? Refactoring.

Map, filter, reduce

If we start with the above example, there is one thing we can do to reduce its cyclomatic complexity, despite it already being so low.

We can replace the loop with a function call that does the same thing.

public function escape($subject) { if (is_array($subject)) { return array_map(array($this, 'escape'), $subject); } if (is_string($subject)) { return "'" . $this->database->escape($subject) . "'"; } return $subject; }

Now the method is only making two decisions. Why is this a good thing?

We aren't reimplementing what array_map already does for us

The method no longer has a loop, making it simpler

Our code is more concise to read

The same approach can be used for common scenarios with the array_filter and array_reduce functions in PHP. There are equivalents in other languages that can be used.

Before you write a foreach loop to apply (map) a function to every value of an array, or to filter elements out of the array, or to reduce an array to a single value, consider using one of these functions.

Method Extraction

One of my most favoured approaches to refactoring code is method extraction. It involves extracting appropriate segments of a method into new methods.

Here are some helpful ways to determine which code can be extracted from a method:

Inline comments that explain the behaviour of a code segment

Code segments that perform tasks that can be isolated

Deeply nested loops and conditionals

Duplicate/similar code segments

Here's a very simple example we can perform method extraction on.

public function set($attribute, $value = null) { $attribute = strtolower($attribute); if ($attribute === 'id') { $attribute = $this->key(); } $this->data[$attribute] = $value; }

This method is used to set attribute data on some object, but if the attribute name is id then said attribute is loaded from another method instead.

We could then write a get() method that's doing the opposite thing - retrieving the data - and use the same code to prepare this attribute variable, but this would introduce duplicate logic between these two methods.

public function get($attribute) { $attribute = strtolower($attribute); if ($attribute === 'id') { $attribute = $this->key(); } return $this->data[$attribute]; }

Instead, we can extract the code that prepares $attribute to its own method, like so.

protected function prepareAttribute($attribute) { $attribute = strtolower($attribute); if ($attribute === 'id') { return $this->key(); } return $attribute; } public function get($attribute) { $attribute = $this->prepareAttribute($attribute); return $this->data[$attribute]; } public function set($attribute, $value = null) { $attribute = $this->prepareAttribute($attribute); $this->data[$attribute] = $value; }

While this could seem like only an elimination of duplicate code, it's also the identification of a code segment that can be isolated. It makes perfect to sense to do this whether the code will be reused or not, especially in more complex cases.

In this case, we have made sure that the same decision is not being made in more than one place. We haven't removed the complexity from the class as a whole, but separated it into simpler components.

Other software metrics

There are many ways other than cyclomatic complexity to analyse your code.

Here are some key metrics that I think are worth understanding, described in relation to classes:

Coupling - How tightly classes depend on each other

Cohesion - The strength of the relationship between the functionalities within a class

Number of lines of code - How long are you letting your class become?

Line count is a very simple one, but it's good to consider how large you let classes become. If you're rapidly approaching 1000 lines then it's helpful to ask yourself why, and what you can do about it (refactor), instead of just letting it happen. In some cases, classes really do need to be that large. If so, it's can be useful to other developers to explain why in its documentation.

Analysis tools

There are many online services you can use to analyse the metrics of your own software. When using them, it's best to treat the problems they raise as a guide to improving your software, not as the one and only truth.

Scrutinizer CI

SensioLabs Insight

Code Climate

Codacy

Scrutinizer is my absolute favourite analysis service, and seems to be the most powerful. It runs multiple analysis tools on your code and presents you with the issues it finds in a simple interface. It also presents guides on how to improve specific code smells as they appear in your code. You'll get clear ratings for the coupling and cohesion of your classes.

Conclusion

The less decisions your methods make, the less chance they have to do something unexpected. This ultimately makes them easier to test. Minimising this risk by simplifying or separating complex code segments can prove really beneficial to maintaining a quality code base.

There are cases in which you wouldn't want to worry too much about certain metrics, and it's also important to use them together to gain a more general introspection into the complexity of your code.

Software metrics will never be the definitive answer to building software in the best possible way, but will always be useful tools that help us get there.

Related

http://www.aivosto.com/project/help/pm-complexity.html

https://www.cqse.eu/en/blog/mccabe-cyclomatic-complexity/

Imagine it like this, you are explaining a friend how to replace a wheel on their car. Everybody would answer: secure the car, take the old wheel off and put the new one in place.

It's basically four simple steps that everyone can acknowledge and understand without requiring a complex manual or algorithm. ou could basically write this into a computer and get something like this:

function replace_wheel() {  secure(car);  remove(old_wheel);  place(new_wheel); }

You just programmed replacing a wheel, with three lines of code. Easy as cake, wasn't it? Programmers instead attempt to do this:

function replace_wheel() {  set_handbrake(car);  place_jack();  for (i = 0; i < old_wheel.screws.length; i++)   unscrew(old_wheel.screw[i]);    take_off(old_wheel);  put_on(new_wheel);  for (i = 0; i < new_wheel.screws.length; i++)   unscrew(new_wheel.screw[i]); }

You notice something? The second piece of code is way longer, and more complex. It wouldn't require you to produce additional functions but it's harder to debug. This is for one simple reason. The second one is a bad function, it does define several functions in itself and therefore will break easily.

There is a whole list of things that will become worse on the second function:

The function will take longer to read. The process will be harder to verify. While the first function allows to quickly verify that it is ok, the second actually takes some time to read.

The variable scope will become crowded. You will start defining longer variable names that may not be intuitive.

More flow control and nesting. Due to you function doing the job of several smaller ones it will contain more if and for statements that increase the complexity.

And here is the main difference: the second has a much higher cyclomatic complexity. Which is calculated by relatively simple function.

In the end, cyclomatic complexity is a complicated term and a scientific explanation on why code wrapped into small, simple and human readable functions is a better approach on coding than big monolithic monsters that make your life harder.