"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.

One method [Ward Cunningham] suggests is that of summarizing on a single line select punctuation characters from each source file. He calls this the file's "signature". This will help the developer gauge the complexity of the code base.

He includes a few examples from files in WordPress - looking for the structure of curly braces and semicolons as delimiters for chunks of functionality. Included are a few lines of code to help you generate a signature from any file and an example of a result. It's an interesting idea, but I'm not sure how practical it is. It could be a helpful reference for how complicated the file is, though.

I'd like to share a topic today which was re-introduced to me by a lightningtalk of a colleague of mine. His talk was on the "big O notation". The big O notation is a tool you can use to express the order of complexity of an algorithm. It is useful because it lets you express the order of complexity of an algorithm without taking a lot of time profiling or researching the underlying algorithm. In other words: it gives you a quick way to gain an understanding of what might be wrong (or right) with a specific algorithm.

He introduces the notation as the result of a series of steps needed to solve a problem (ex. 2+2 is less complex than 2+2+2). He illustrates with PHP examples that show adding complexity to a class, adding sets of numbers, looping to find needles in haystacks and finding duplicates in an array of strings. Each of these expand on the theory and show more complexity as the article progresses.

Here's a counterpoint to the currently popular view of "fat controllers are bad", and the current fad of everyone and their cousin implementing service layers: You don't need one. Fat controllers are okay too.

He starts by explaining the "why you don't need a service layer" part, mentioning that keeping it in the controller keeps things simple and keeps your code from having to go through extra hoops just to work correctly. He also points out that, just because he recommends "fat controllers" doesn't mean he's advocating code reuse. In fact, just the opposite:

It's fine if you code your things in the controllers, but there comes a point when you should stop that. The moment you realize you're duplicating your code, stop and refactor. This is one of the very basics of software engineering: Avoid duplication by creating functions and classes.

PHP_CodeCoverage is a component that provides collection, processing, and rendering functionality for PHP code coverage information. [...] Having all code that deals with code coverage in a separate component allows for easier development and better testing. The first result of these improved development conditions is a small new feature that I recently implemented, the support for the CRAP metric.

Your code's CRAP (Change Risk Analysis and Predictions) scoring combines the idea of cyclomatic complexity and code coverage statistics to try to guess at how difficult any given piece of code would be to maintain. You can see an example here - the lower the number the better.

Don't assume that just because you're using an object-oriented framework you are writing reusable and maintainable code. You are just structuring your spaghetti code. [...] The main problem with flexibility is that most developers give up trying to understand. I don't blame them, no one likes dealing with complexity

TO illustrate, he gives two code snippets from two example developers - Developer A makes full use of the framework and takes a more compact approach to the problem while Developer B adds in a bit more checking and takes a different path to the same (basic) end result.

In the following podcast I go over the key factor when determining how to structure a PHP project. In a nutshell, it comes down to the size and complexity of the job. For the details, listen to me yap.

You can download the mp3 directly from his site. For more great PHP tutorials, check out his videos section.

Starting off with "However, I'm not really the type of person to give accolades unless something is absolutely stellar. As such, this post will primarily be about the shortcomings of the book" I wasn't particularly surprised that there was more of a focus on negatives rather than positives.

Michael mentions three topics - the "first to market" point the reviewer makes about different versions of Magento between the book being authored and the release, some of the missing information the reviewer would've liked to see and the complexity of the example module that the reviewer complains is too hard to follow.

I believe understanding the patterns in your own thinking will by far make the biggest impact on how good you will get as a programmer. Forget design patterns, forget unit testing, forget all those functions you know. Important is to question why they exist and how they could be improved.

He illustrates through a few examples what he means. He describes one such thought method, the "return home early" process - basically, if something looks too complex for its own good, it probably is. He offers a different way of thinking about it too, a more visual way that can help simplify things even more by laying out the pieces and seeing where they all fit.

The Change Risk Analysis and Predictions (CRAP) index is to give some idea how difficult it would be to maintain the code base. It is not to be used in evaluating how "beautiful" the code is.

He had to modify things slightly in PHPUnit to get it to work with entire files/functions, but it was still simple to use the testing software to create each file's CRAP index. For his examples, he chose the WordPress code and includes the code he used for the tests - two functions: getCCLevel and getCrapIndex. The results of the report are also included.