In his latest post Tomas Votruba shares some of his thoughts around the importance of code readability and the idea of "cognitive complexity".

Cyclomatic complexity is a static analysis measure of how difficult is code to test. Cognitive complexity tells us, how difficult code is to understand by a reader.

Today, we'll see why is the later better and how to check it in your code with a Sniff.

He references this post and this PDF as sources for more information about cognitive complexity but opts for code examples to explain some of the basic concepts. He then gets into the automation of these kinds of checks, using a custom code sniff to check the complexity of the code. He walks through the installation process of the CognitiveComplexitySniff and shares some example results from its evaluation.

In a post to his site, Matthias Noback talks about code complexity and how this relates to the overall "churn" (the rate of change) in a project.

Code complexity often gets measured by calculating the Cyclomatic Complexity per unit of code. The number can be calculated by taking all the branches of the code into consideration. [...] In general, we always strive for low code complexity. Unfortunately, many projects that you'll inherit ("legacy projects"), will contain code that has high code complexity, and no tests.

[...] Code complexity doesn't always have to be a big problem. If a class has high code complexity, but you never have to touch it, there's no problem at all. [...] What's really dangerous for a project is when a class with a high code complexity often needs to be modified. Every change will be dangerous. [...] Michael Feathers introduced the word "churn" for change rate of files in a project. Churn gets its own number, just like code complexity.

He then talks about combining these two numbers to provide an even more in-depth look at your code. It can give more insight into the relationship between "difficult to change", "number of changes" and the times a file has changed in the past. He mentions "it's okay" thinking (the current state is alright but not great) and shares some of his own hypotheses, observations and advice.

On the Laravel News site there's an article posted showing you how to determine the complexity of your application using the phploc tool from Sebastian Bergmann.

Yesterday, Taylor made a post comparing the code complexity between Laravel and other frameworks. The tool he used to generate these reports is called phploc and it’s very easy to run on your own code base.

I decided as a means of comparison I would run that on the codebase for this site and just see what the results are.

The tutorial walks you through the installation of the tool (as a globally installed Composer package), how to execute it and what the results look like. These results include a lot of data including:

• Average Class Length
• Average Complexity per LLOC
• (Use of) Global Constants
• (Number of) Namespaces

phploc is useful for getting the overall numbers but he wanted something a bit more specific. For that he chose the PhpMetrics package that allows for deeper introspection into files and classes in your code to locate the complexity and find spots for refactoring.

On Medium.com Taylor Otwell, lead developer and creator of the Laravel framework, has posted some results about framework code complexity based on his own research and information gathering.

Last week as I was refactoring and cleaning Laravel for the 5.4 release, Graham Campbell showed me some code complexity statistics for the framework. I decided to compare this against some other PHP frameworks to see how Laravel stacks up.

[...] I was pleased to see Laravel has the lowest average method complexity of any of the frameworks measured. In addition, Laravel does not contain any method longer than 13 lines of code. [...] The primary goal of this comparison is to compare how I personally write code vs. how other projects are writing code. All project’s measured have a large enough sample size of pure, first-party code to accurately measure that.

He then shares the cyclomatic complexity numbers for several different (and popular) frameworks in the PHP ecosystem:

• Laravel
• Symfony
• Zend Framework
• Cake
• Slim

He also compares just the Eloquent ORM and the Doctrine ORM components. For each he provides stats like: lines of code, average method complexity and percentage of methods that are non-static. The results are interesting but most are pretty much expected (like the Slim microframework being lowest on several of the statistics mostly due to its size).

In this post to his site Marc Scholten talks about something that's become a side effect of using the inversion of control design pattern in PHP applications (specifically related to dependency injection): added accidental complexity.

Modern PHP development favors the use of inversion of control to keep software more configurable and flexible. This leads to the problem that one now has to create a big graph of objects to use the application. As a solution to avoid redundant setup code, service containers like the symfony2 dependency injection component are used.

The goal of a service container is to centralize the construction of big object graphs. [...] Simple, right? Actually it’s not. Commonly used service containers are complex solution for simple problems.

He illustrates with an example using the Symfony services container, a piece of the framework that allows the definition of dependency relationships via a YAML formatted file. While this configuration seems simple enough, he points out that more complex dependencies (ones that could easier be set via a "set" method) become more difficult to define when limited by the service container config structure. He also points out that it makes static analysis of the code much more difficult with dependencies being dynamically fetched from the container instead of directly related. He offers an alternative to this complex container setup, however: a simple method (or methods) inside of a factory class that creates the objects, injects the required dependencies. This makes it much easier to call from the service container instance and configuration and even a "create container" call to set all of the dependencies up at once. He ends the post with some advantages of this approach and a takeaway or two to keep in mind when managing your object dependencies.

On the Ibuildings blog Matthias Noback has kicked off a series that wants to help PHP developers reduce the complexity of their applications. In part one he shares some general tips along with code snippets illustrating the change.

PHP is pretty much a freestyle programming language. It's dynamic and quite forgiving towards the programmer. As a PHP developer you therefore need a lot of discipline to get your code right. Over the years I've read many programming books and discussed code style with many fellow developers. I can't remember which rules come from which book or person, but this article (and the following ones) reflect what I see as some of the most helpful rules for delivering better code: code that is future-proof, because it can be read and understood quite well. Fellow developers can reason about it with certainty, quickly spot problems, and easily use it in other parts of a code base.

The rest of the article is broken up into several changes you can make to reduce complex code including:

• Reduce the number of branches in a function body
• Create small logical units
• Using single (variable) types
• Making expressions more readable

He ends this first post in the series with a mention of a few other books to read up on around the subject of "clean" and less complex code.

On the Procore blog there's an excellent article covering their thoughts on the evolution of software applications and the different stages they go through during their development.

If you develop software long enough, you notice patterns. One pattern that isn’t talked about enough is how systems evolve over time.

The software industry is so focused on the flavor of the week that we lose perspective. Most of what is “invented” today was created decades ago. Most problems we face today were solved by someone else.

Software developers don’t have a good understanding of our own history. In the spirit of that, I present to you my take on how software tends to evolve and why.

He starts by defining a term that is used through the rest of the article, software gravity, and illustrates how it relates to development time and complexity. He then gets into describing the seven stages of software evolution as he sees them (starting with zero, naturally):

• Stage 0: Humans, Paper, and Spreadsheets
• Stage 1: Simple Script
• Stage 2: Pile Of Files
• Stage 3: The Framework
• Stage 4: Beyond The Framework
• Stage 5: Modularization
• Stage 6: Network System

For each of the points he provides an overview of what the application might be like at this stage and what levels the complexity/gravity are at. The post ends by asking about a "Stage 7" and if it even exists, suggesting that it might be an even further abstraction from previous steps.

On the /r/php subreddit on Reddit.com, TheSkilletHead wonders if ORMs are inherently limiting in PHP development. Their main point is that, in abstracting and simplifying the interface the developer has to work with, some of the power of the complex database handling is lost.

I don't feel like I'm asking too much from an ORM. I'm not asking for the ORM to manage database-side functions. I'm not asking it to manage database-side variables. I'm not asking it support every type of INSERT (like INSERT DELAYED). I'm OK that it doesn't support LOAD DATA INFILE. I'm even OK with the overhead. However, when I look up why Doctrine doesn't support UPDATE ... JOIN and the response is "it's too different across database engines", then I'm a bit disappointed because that seems to be why one would use an ORM in the first place. [...] Can an ORM be a useful tool to abstract the database or is it just a crutch for people who can't be bothered to learn SQL?

There's quite a few comments on the post already, most confirming his opinion that ORMs are limiting. Some, however, note that they don't have to be. There are some (like the CakePHP 3 ORM) that do have some more advanced features and are still easy to use. Despite this, most of the comments are about developers moving away from ORM use towards more specific, customized solutions that are a better fit for their needs and database systems.

The SitePoint PHP blog has a recent post looking at time complexity in the algorithms you develop in your PHP applications and how that relates to "Big O notation". Big O notation is simply a way of expressing complexity and performance of a method in a less subjective way than "it's faster than.."

If you are a web developer or a programmer in general, you have most likely written algorithms for various tasks. [...] One specification of an algorithm is its correctness. You will probably assume that your algorithm works after testing it out a few times. However, if you can mathematically prove that your algorithm will work as expected for every input value possible, this is a huge bonus. I will not go further in to that subject in this writing. Another specification is its efficiency: how does the computing time relate to the amount of input? Is it a linear relation? Does computing time rise exponentially for the doubling of input? That’s what this article will be about.

He starts by talking about the concept of "time complexity" and how it relates to the overall efficiency of the algorithm. He then gets into the definition and examples of Big O notation, including code showing O(n) and O(n²) methods. He talks some about inefficient and efficient algorithms and follows with a refactoring example of moving from one to the other.

In a new post to his site today Andrew Podner takes a look at NPATH and tries to "demystify" some of the concepts around it.

“NPATH, which counts the acyclic execution paths through a function, is an objective measure of software complexity related to the ease with which software can be comprehensively tested.”[1] This is the definition from an article written in 1988 by Brian Nejmeh. As informative as this is, my eyes glazed over half way into it. So what the heck is acyclic execution anyway?

He defines the term in a bit easier to understand language and includes an example function to help illustrate how NPATH is measured.

The goal is to limit your NPATH complexity in a given method down to 200 or less. [...] As with other complexity metrics, this one can be checked with PHP Mess Detector (phpmd). The importance of staying under the 200 path threshold is realized when you develop tests and start trying to debug.